>Там указывается на очень большое число «но», заставляющих очень сильно подумать о том, что стоит ли вообще уходить с надежной-стабильной-вечной ext3/ext4.
Ric Wheeler (who wrote the paper) is the architect/manager for Red Hat's file system team and was personally involved in choosing XFS as the default. In addition, Red Hat Storage (when Ric managed that team) followed many storage partners and mandated over a year ago already that XFS would be the only file system supported in Red Hat Storage 2.0.
стабильность и надежность ext3/ext4 — миф. ext3 — тормоз. жуткий тормоз и пережиток из прошлого.
с ext4 ситуация чуть лучше(о, там появились экстенты), но вот число inode там по-прежнему задается при создании фс, по-прежнему нужен fsck и проч-проч.
у ext4 по-прежнему проблемы с производительностью(многие операции упираются в журнал), она генерирует больше iops на одинаковых с xfs паттернах. это если не вспоминать про отсутствие средств диагностики у ext4(вот банальную фрагментацию фс как на ней посмотреть?) и лечения(да, в xfs есть онлайн-дефраг).
отдельные фишки, вроде realtime subvolume нужны единицам, но всё-таки тоже иногда надо.
Другая сторона вопроса, когда доходит до реальной эксплуатации. Стоит ли заменять работающую на тысячах физических машин ext3/ext4 на XFS, суляющую в общем-то не шибко радикальные преимущества?
у меня пара небольших стораджей на 20Тб, которые всегда заняты на 95%, там ~ 6-8млн файлов(размером от 4кб до 16Мб), бывают шквалы записи по 700-900Мб/с, чтение/запись ближе к линейному. и в таком режим оно живёт уже третий год.
там раньше была ext4 и чего я только не пытался тюнить.
xfs_db> frag
actual 1804489, ideal 1786692, fragmentation factor 0.99%
но эта цифра — результат переписывания приложения с целью создания тепличных для фс условий(пишем только когда знаем конечный размер файла). не всегда есть возможность такой оптимизации.
раньше фрагментация была 30-40% и всё так же работало. ext4 в тех же условиях ставила всё колом(здравствуй jbd2 в iotop).
Уважаемый комментатор, вы если владеете методикой обновления дистрибутива до актуальной версии
если я вижу что-то действительно интересное — я пишу заметки на opennet.ru
но описывать очевидные вещи смысла не вижу совсем.
ваша проблема не техническая, она — административная.
Но при всем этом базовой ФС многих систем остается ext4 с текущим лимитом размера ФС в смешные 16Тб (RHEL6), в свою очередь RHEL7 предоставляет killer-фичу — размер ext4 до 50Tb, что в свою очередь вопрос даже не завтрашнего дня, а вчерашнего, так как это уже довольно малые цифры. Да и на ext4 такие емкости использовать местами страшно.
впрочем, кто следит за развитием файловых систем в linux врядли удивился, т.к. Dave Chinner очень много сделал как для самой xfs(а работает он в redhat), так и для других файловых систем.
если кто не знает, это он в последних релизах ускорил fsync на порядок для некоторых ситуаций.
Так вот, я абсолютно уверен, что RedHat никогда не добавит ZFS даже модулем, даже в отдельном пакете.
ну не добавит — и ладно. есть много различных сторонних модулей, некоторые вы вообще никогда не увидите в исходниках(вроде VxFS). какая разница, кто? важно чтобы работало.
Ок, давайте представим текущую картину, какие усилия нужно предпринимать для поддержки ZFS как модуля во всех основных дистрибутивах, используемых сегодня:
1) CentOS/RHEL 6 — ядро 2.6.32 от RedHat
2) Debian 7 — ядро 3.2, почти ванильное
3) Ubuntu 12.04 — ядро 3.8, почти ванильное
4) CentOS/RHEL 7 (выйдет буквально в ближайшие месяцы) — ядро 3.2 от RedHat (стоит отметить, что это ядро и ядро того же Debian 7 — две огромных разницы, разница в коде межды ними, боюсь, за миллионы строк, так что это разные ядра)
5) А еще есть Fedora, с 3.12 ядром и еще много-много других дистрибутивов
zfsonlinux сделан очень правильно: есть spl(solaris porting layer), абстрагирующий от ядра linux и собственно сам zfs. похожим образом zfs портирована во freebsd.
так что если даже ограничиваться поддержкой — никаких фантастических ресурсов не надо.
(да и проблем с ресурсами у LLNL, где работает Брайан особо нет).
4) CentOS/RHEL 7 (выйдет буквально в ближайшие месяцы) — ядро 3.2 от RedHat (стоит отметить, что это ядро и ядро того же Debian 7 — две огромных разницы, разница в коде межды ними, боюсь, за миллионы строк, так что это разные ядра)
я в курсе. но не 3.2, а 3.10 и проблем с zfs там, afaik, нет.
Zones other than the global zone have restricted access to the network. The standard TCP and UDP socket interfaces are available, but SOCK_RAW socket interfaces are restricted to Internet Control Message Protocol (ICMP). ICMP is necessary for detecting and reporting network error conditions or using the ping command.
т.е. анализатор трафика не запустишь.
Oracle Solaris IP Filter can be enabled in non-global zones by turning on loopback filtering as described in Chapter 21, IP Filter (Tasks), in Oracle Solaris Administration: IP Services.
т.е. сделать неглобальную зону, через которую бегает весь трафик глобальной зоны — никак.
IP Network Multipathing in Shared-IP Zones. All network configuration is done in the global zone. You can configure IPMP in the global zone, then extend the functionality to non-global zones.
т.е. всё это больше похоже на venet в openvz. да, в солярисе классные утилиты управления, документация итп. но по возможностям она проигрывает.
Но организационно лишь полтора-два дистрибутива (RedHat, Oracle, вроде и все) могут позволить себе поддерживать версию ядра отличную от того, что есть на Kernel.org.
вы ставите какие-то странные цели, а потом декларируете сложность их достижения.
А вот если фича попадает в ваниальное ядро (upstream), то она почти сразу же попадает во все дистрибутивы. Кроме этого, так как фича «стандартная» и есть везде, то сразу же подтягивается и user space окружение и система интегрируется везде и вся.
вы, мягко говоря, не правы. в той же 12.04 lts ядро 3.2 и поддерживаться оно будет afaik, до 2017 года.
причём, не правы как в первом утверждении(про сложность поддержки отличного от ваниллы), так и во втором(про быстроту появления фич).
А сейчас у нее три десятка «вендоров», которые максимум осиливают — поменять формат сжатия (FreeBSD) или, например, усилить контроль четности. Вся остальная их работа сводится к тому, что они портируют Sun'овский CDDL'ный код на новое окружение.
Потом выяснилось, что один из долгоиграющих процессов открыл дескриптор большого файла (лога чтоли, не помню, не суть) и писал в него. Запись в каталоге о файле удалили
за такое надо бить больно по рукам )) причем всем: и тем, кто писал код… и тем, кто так удаляет :)
я знал, что вы туда сошлётесь :) ну нет в posix.1-2001… и что? :)
linux-зависимость — это epoll/splice/vmsplice/fincore. но явно не достаточно портабельный sendfile.
А вообще, методика тестов странная, как и выводы.
настройки sysctl.conf странные, mbuf-кластеров мало, цифр по netstat/vmstat -z нет.
я писал однопоточный http-сервер на python(gevent) и без каких-либо ухищрений он выдавал 11k rps. тесты выполнялись на реальном железе через линк в 1GEx2.
это написанное на интерпретируемом языке и без jit. есть у меня мысли перенести это на pypy и посмотреть цифры.
for x in lst[4]:
all.append(x[0])
all.append(x[1])
all.append(x[2])
all.append(x[3])
all.append(x[4])
all.append(x[5])
all.append(x[6])
all.append(x[7])
Владимир Ильич? Жаль, что его хотят закопать =(
стабильность и надежность ext3/ext4 — миф. ext3 — тормоз. жуткий тормоз и пережиток из прошлого.
с ext4 ситуация чуть лучше(о, там появились экстенты), но вот число inode там по-прежнему задается при создании фс, по-прежнему нужен fsck и проч-проч.
у ext4 по-прежнему проблемы с производительностью(многие операции упираются в журнал), она генерирует больше iops на одинаковых с xfs паттернах. это если не вспоминать про отсутствие средств диагностики у ext4(вот банальную фрагментацию фс как на ней посмотреть?) и лечения(да, в xfs есть онлайн-дефраг).
отдельные фишки, вроде realtime subvolume нужны единицам, но всё-таки тоже иногда надо.
у меня пара небольших стораджей на 20Тб, которые всегда заняты на 95%, там ~ 6-8млн файлов(размером от 4кб до 16Мб), бывают шквалы записи по 700-900Мб/с, чтение/запись ближе к линейному. и в таком режим оно живёт уже третий год.
там раньше была ext4 и чего я только не пытался тюнить.
но эта цифра — результат переписывания приложения с целью создания тепличных для фс условий(пишем только когда знаем конечный размер файла). не всегда есть возможность такой оптимизации.
раньше фрагментация была 30-40% и всё так же работало. ext4 в тех же условиях ставила всё колом(здравствуй jbd2 в iotop).
может, всё-таки речь о каком-то конкретном демоне?
ок. например, запустить pppoe-сервер внутри контейнера. хотя, да. в солярисе с этим же плохо. как и с пакетным фильтром.
если я вижу что-то действительно интересное — я пишу заметки на opennet.ru
но описывать очевидные вещи смысла не вижу совсем.
ваша проблема не техническая, она — административная.
XFS as default in EL7
впрочем, кто следит за развитием файловых систем в linux врядли удивился, т.к. Dave Chinner очень много сделал как для самой xfs(а работает он в redhat), так и для других файловых систем.
если кто не знает, это он в последних релизах ускорил fsync на порядок для некоторых ситуаций.
Вообще, всем стоит посмотреть вот этот его доклад на linuxconf.au 2012
ну не добавит — и ладно. есть много различных сторонних модулей, некоторые вы вообще никогда не увидите в исходниках(вроде VxFS). какая разница, кто? важно чтобы работало.
ок. «The kernel API changes frequently, version 0.6.2 supports 2.6.26 — 3.11 kernels.» © zfsonlinux
zfsonlinux сделан очень правильно: есть spl(solaris porting layer), абстрагирующий от ядра linux и собственно сам zfs. похожим образом zfs портирована во freebsd.
так что если даже ограничиваться поддержкой — никаких фантастических ресурсов не надо.
(да и проблем с ресурсами у LLNL, где работает Брайан особо нет).
я в курсе. но не 3.2, а 3.10 и проблем с zfs там, afaik, нет.
т.е. анализатор трафика не запустишь.
т.е. сделать неглобальную зону, через которую бегает весь трафик глобальной зоны — никак.
т.е. всё это больше похоже на venet в openvz. да, в солярисе классные утилиты управления, документация итп. но по возможностям она проигрывает.
больной, не делайте так!
я вот создавал нужные мне эталонные образы через debootstrap и никакого grub и ядра там не было.
вы ставите какие-то странные цели, а потом декларируете сложность их достижения.
вы, мягко говоря, не правы. в той же 12.04 lts ядро 3.2 и поддерживаться оно будет afaik, до 2017 года.
причём, не правы как в первом утверждении(про сложность поддержки отличного от ваниллы), так и во втором(про быстроту появления фич).
тут вы тоже не правы. смотрите:
zfsonlinux сделал фичу
фичу втащили в freebsd-head, попутно улучшив
улучшения из freebsd-head втащили в zfsonlinux
потом оно уехало в illumos(можете сами найти). так что никаких сложностей нет.
код фс общий для illumos/freebsd/linux, изменения кочуют туда-сюда.
я достаточно давно писал про network namespaces в linux
ок, поговорим о crossbow вот в каком ключе: можно ли там иметь свой набор правил пакетного фильтра внутри зоны?
по уму — есть syslog.
за такое надо бить больно по рукам )) причем всем: и тем, кто писал код… и тем, кто так удаляет :)
linux-зависимость — это epoll/splice/vmsplice/fincore. но явно не достаточно портабельный sendfile.
настройки sysctl.conf странные, mbuf-кластеров мало, цифр по netstat/vmstat -z нет.
я писал однопоточный http-сервер на python(gevent) и без каких-либо ухищрений он выдавал 11k rps. тесты выполнялись на реальном железе через линк в 1GEx2.
это написанное на интерпретируемом языке и без jit. есть у меня мысли перенести это на pypy и посмотреть цифры.
с чего бы вдруг сендфайл стал linux-зависимостью?! :) тем более, что в freebsd/solaris он тоже есть?
и для генератора нагрузки sendfile() не нужен. разьве что для POST'а.
>>> all <built-in function all>зачем так длинно, если можно
аналогично.
можно просто
это быстрее и короче.