Вышла статья "XFS: структура и алгоритмы (http://www.filesystems.nm.ru/my/xfs_arch.pdf)" (PDF, 360 Кб). В документе подробно рассмотрены дисковый формат, алгоритмы работы драйвера, специфические оптимизации.
Кроме того, можно отметить представленный ранее перевод документа "Масштабируемость в файловой системе XFS (http://www.opennet.me/soft/fs/xfs_arch.pdf)".URL: http://www.filesystems.nm.ru/my/xfs_arch.pdf
Новость: http://www.opennet.me/opennews/art.shtml?num=19847
Кто не в курсе, вышла 3.0.0 версия xfsprogs
странно
на kernel.org тока 2.10.2 от декабря валяется
http://xfs.org/index.php/XFS_Status_Updates"... xfsprogs is getting close to have the 3.0.0 release which will be the first full resync with the kernel sources since the year 2005."
А ты про CXFS (Clustered XFS) Их там не пытал? Открывать будут??? :)
http://www.sgi.com/products/storage/software/cxfs.html
http://www.sgi.com/pdfs/2816.pdf (PDF x.зKb)
Надёжная, бастрая ФС, особенно хороша на томе с "крупногабаритным" медиа. Использую на ровне с EXT3 и ReiserFS3. Познакомлюсь с ней поближе :)
>Надёжная, бастрая ФС, особенно хороша на томе с "крупногабаритным" медиа. Использую на
>ровне с EXT3 и ReiserFS3. Познакомлюсь с ней поближе :)Когда познакомишься поближе, тогда и расскажешь о её надёжности. :D
>>Надёжная, бастрая ФС, особенно хороша на томе с "крупногабаритным" медиа. Использую на
>>ровне с EXT3 и ReiserFS3. Познакомлюсь с ней поближе :)
>
>Когда познакомишься поближе, тогда и расскажешь о её надёжности. :DЯ чисто с обывательской точки зрения. Из личного опыта. Когда наводил справки по этой ФС, те, кто твердил что XFS - сырое говнище и вообще не нужна, ext3 наше всё, кажется остановили планку своего развития года эдак 4 назад. Я не жалуюсь. Пользуюсь на домашнем ПК (на работе в всязи со спецификой - венда. А так бы и там пользовался.), данные и после прерывания питания не терял, не говоря уж о порче ни стого, ни с сего.
>и вообще не нужна, ext3 наше всё, кажется остановили планку своего
>развития года эдак 4 назад.Все так.Думаю что даже больше: EXT4 сделанный вот-вот только что - всего лишь банальное вытягивание EXTов до состояния которое у других ФС было уже 5-6 а то и более лет назад.Достаточно посмотреть на то когда у других ФС появились экстенты и B-деревья а линейные списки и т.п. структуры типа битовых карт и таблиц перестали юзать из-за проблем масштабирования ;).Поэтому те кто твердит что ничего кроме EXT'ов не нужно - или просто забыли отпустить ручник или некрофилы со стажем или под их задачи "5-летний комп с одним HDD 5-летней давности" им его и правда хватает.А как посмотришь на скорость работы XFS с большими файлами, обувать себя на это может и не захотеться... если с умом делать, зная сильные и слабые стороны ФС - все ок.
>>Надёжная, бастрая ФС, особенно хороша на томе с "крупногабаритным" медиа. Использую на
>>ровне с EXT3 и ReiserFS3. Познакомлюсь с ней поближе :)
>Когда познакомишься поближе, тогда и расскажешь о её надёжности. :DИспользую десятками годо-хостов, доволен. Общая формула -- "XFS+UPS", в т.ч. дома.
>Надёжная, бастрая ФС, особенно хороша на томе с "крупногабаритным" медиа. Использую на
>ровне с EXT3 и ReiserFS3. Познакомлюсь с ней поближе :)Вообще, исторически эта "надежная" ФС известна своим занулением данных в файлах =).Хотя это долго и упорно чинили.Насколько починили - хрен знает: при юзании XFS предпочитаю не тестировать это на реальных данных, подперев упсой и по возможности преимущественно большие файлы, по возможности в основном read-only.Так можно пользоваться плюсами XFS не знакомясь с (хрен его знает добитыми ли) минусами :D.
скажите а есть в природе драйвер XFS под винду?
ro точно есть.
Насчет rw не уверен.
ссылку в студию!
http://google.com
>ссылку в студию!Были у crossmeta.com но судя по сайту - бобик сдох... при том кажется не доведя драйвера до ума. Да и вообще, пора уже привыкнуть что под винды по части ФС - попа.Микрософт сам ее создал потребовав бабла за SDK и забив болт на развитие этого направления.Ну вот и получается что всерьез в винде можно выбирать между антикварным фат32 да NTFS, склонным к фрагментации и не сильно то и быстрым.Еще есть сторонний ext2 драйвер.Без журналирования и ттооррммоозз.Ну вот пусть виндузятники и выбирают, ха-ха =)
Пытался использовать эту ФС на массиве 22ТБ, пробовал делать проверку, спустя некоторое время вывалилась из-за нехватки ОП (было 4ГБ).
Остановился на JFS, вроде все нормально.
Не осилили документацию.
Пытался использовать эту фс на четырех машинах. Все четыре рухнули в течении года по идентичной причине - отключение питания на ходу. Момент сбоя зафиксировать сложно, но при активности rw на файловой системе после сбоя она крайне быстро деградирует до полного разрушения. Теряются файлы, обнуляются, заполняются не тем содержимым. Как правило если такой сбой произошел достаточно месяца для 50%-ного разрушения, я бы назвал "периодом полураспада" :))))
RTFM, RTFM и ещё раз RTFM, как завещали Гей-Люссака, Бойл-Марриот, Шарп, и постоянный Больцман :)особенно на тему
mkfs.xfs
-d agcount=n, agsize=n
-l agnum=n,size=num,version=n
-n size=num,version=nа так же
mount -t xfs на предмет osyncisosync, inode64, logbsize=nНадеюсь вы на сервере, НЕ додумались включит noatime, nodiratime...
Ах да, и можно глянуть команду проверки XFS
И зачем же на сервере этот идиотизм atime?
>-d agcount=n, agsize=n
>-l agnum=n,size=num,version=n
>-n size=num,version=nНу и что там особо наоптимизируешь? Там вполне разумные умолчания считаются, да и по страйпам лучше не разложишь. Вот lazy-count интересней. И вынос журнала на отдельный шпиндель, говорят -- мне вот всё как-то не доводилось, больше восьми дисков на тушку не осваивал.
>mount -t xfs на предмет osyncisosync, inode64, logbsize=n
Спасибо, надо будет глянуть.
>Надеюсь вы на сервере, НЕ додумались включит noatime, nodiratime...
Включил, конечно. :-P
> Там вполне разумные умолчания считаются,Я не думаю, что 16 или 32 allocation group (-d agcount=32), или сколько там по умолчанке,
на 22Tb это есть хорошо...Я бы выставил по 128Gb mkfs.xfs -d agsize=128Gb (или в среднем 2-4 группы на физический диск)
>Надеюсь вы на сервере, НЕ додумались включит noatime, nodiratime...Типа XFS настолько быстро работает что необходимо ему подгадить?Внимание, вопрос: а нахрен время доступа на сервере?Если к файлам интенсивно обращаются оно не имеет практического смысла.А вот протормозить ФС - может.
>Остановился на JFS, вроде все нормально.По скорости средненький какой-то (наверное потому и не юзается особо?).К рассыпаниям вроде не склонен - во всяком случае у мну с jfs никогда не было проблем, даже без подпирания упсой.В интернете тоже как-то матюков на разрушения jfs томов не густо - хороший признак на мое имхо.В итоге - ФС как ФС.Вполне юзабельная вроде.
Около полугода пользуюсь (домашняя машина), все ок. Отключение питания было много раз. То, что файлы медленно удаляет - да, есть. В остальном все хорошо.
Файлы она кстати значительно быстрее удаляет чем ext2/3.
Только это не повод, чтобы рисковать данными ради сомнительных удовольствий.
ext3 наше все. относительно медленная, но проверенная временем и нештатными ситуациями.
> ext3 наше все. но проверенная временемПро время..... уже смИшно. :)
ах.. ах... прямо и не знаю что сказать. это прямо поветрие какое-то - фс ругать.
мне вот ext на lvm вполне устраивает. одно из лучших решений на данный момент.
лучшее назовёте?
>мне вот ext на lvm вполне устраивает. одно из лучших решений на
>данный момент.Лучших чем что?С чем сравнивали?В какой ситуации?И чем лучше?А то анекдот про "армяне лучше чем грузины" вспоминается.
>лучшее назовёте?
Не, так не пойдет - вы кукарекнули что одно из лучших - вам и обосновывать.Я вот у XFS вижу явное преимущество в такой конфигурации: он за счет своего layout запросто размажется на несколько дисков с соответствующей прибавкой в скорости.Если диски могут работать параллельно - XFS в разы выиграет в скорости, не выдвигая каких-то специальных требований к организации всего этого - лишь бы параллельно работало.EXT-ы это смогут далеко не всегда(только если специально подыграть, например, stripe-ом).Ну и на больших файлах XFS традиционно лучше.На куче мелочи XFS ничего шедеврального не покажет.Более того - время удаления в некоторых случаях клиническое - наблюдал как XFS стирал файл на 4Гб секунд 30...но его качали торентом и без предварительной аллокации - похоже найден метод эффективно подгадить XFS`у ;)
>На куче мелочи XFS ничего шедеврального не покажет.Более того
>- время удаления в некоторых случаях клиническое - наблюдал как XFS
>стирал файл на 4Гб секунд 30...но его качали торентом и без
>предварительной аллокации - похоже найден метод эффективно подгадить XFS`у ;)У меня домашняя машина используется в основном как битторрент клиент, два диска по 300 гб без райда, в районе 400 гигов в раздаче, сеть 100 Мбит, камень Athlon X2 4200+, два гига памяти. Эксперементировал с фс, в порядке производительности ext3-reiser3-xfs. Разница реально в разы. Я не знаю че там у вас за сервера используются, но могу сказать что при нормальном аплоаде/даунлоаде скорость примерно на ext3 - 3-4 Мбайт в секунду, reiser3 в районе 7-8 и XFS 11 - т/е в случае XFS закачка идет на полной скорости сетевого интерфейса. Как вы понимаете для современного винта скорость 10 мегабайт/с просто ничто. Внимание вопрос. Куда девается скорость в случае ext3 (у reiser'а понятно - проц грузится)?
По поводу стабильности (из личного опыта) неприятно удивляет ext3 - в случае сбоя питания вероятность обрушения при последующей проверке fsck в районе 10-30 процентов. Лучше всего себя ведет reiser3, ставил людям шлюзы на нем, работали прекрасно на сыпавшихся винтах. Шлюзы собраны из хлама. Да здравствует Linux.
>сказать что при нормальном аплоаде/даунлоаде скорость примерно на ext3 - 3-4Я совсем не против того что XFS быстр на чтении, особенно больших файлов.Собственно я его за это и юзаю.Но вот скорость удаления таких файлов вы тут вроде нигде не указали.Я ругался *только* на скорость удаления файлов в этом случае.А вы ее вообще не привели ;).И собственно про мелочь - тоже по нулям.На мелочи получается что-то заурядное, на уровне прочих ФС без откровенных ляпов (как то человеческое индексироание каталогов, etc).
>Как вы понимаете для современного винта скорость 10 мегабайт/с просто ничто.
На линейном доступе - да.А при seek - я и 700 кил/сек на засраном нтфс томе видел.Прикиньте?На seek туда-сюда жесткие диски сливаются как и много лет назад.
>Внимание вопрос. Куда девается скорость в случае ext3 (у reiser'а понятно
>- проц грузится)?Фрагментация, имхо.Если файл не преаллоцировать - то что делает торент без преаллокации мягко говоря для ФС не подарок - много мелких дозаписей в файл.Самое оно для фрагментации ;)
>По поводу стабильности (из личного опыта) неприятно удивляет ext3 - в случае
>сбоя питания вероятность обрушения при последующей проверке fsck в районе 10-30
>процентов.Сказки какие-то.На моих глазах питание рушилось многократно.И ничего не сыпалось особо.Хотя для полной уверенности можно журналить *ВСЕ*, но это меееедлеееееенно и обычно оверкилл.Но если данные на томе очень ценные а скорость не важна - why not?
>Лучше всего себя ведет reiser3,
Что, прямо вот так везде?Сказки (при том это можно про любую ФС сказать).Нету там серебряной пули.Для любой ФС найдется задачка которая ей не подходит.Поищите тут на опеннете ссылку на бенчмарк не столь древний.При всей бестолковости бенча кой-что интересное в нем есть - в частности видно что рейзер страдает от фрагментации.
>работали прекрасно на сыпавшихся винтах. Шлюзы собраны из хлама.
Ну, знаете, я не думаю что кого-то там целостность данных волновала вообще, так что ценность этой информации имхо невелика.
>ext3 наше все. относительно медленная, но проверенная временем и нештатными ситуациями.Не относительно, а дико; временем и ситуациями проверено ровно то, что рассыпаться она тоже умеет. Хоть и более деревянная.
Если у Вас пока не рассыпалось -- хорошо, но сами понимаете, мало о чём говорит.
рассыпаться умеет всё.
лет 15 уже "пока". и "пока" нормально.
а нужно лучше? берем её же и лвм.
>лет 15 уже "пока". и "пока" нормально.По всей видимости, аффтар не знает, какой сейчас год и с каком году ext3 появилась в ядре - значит просто берет на понт
"аффтар" имеет ввиду свой опыт работы с фс вообще и с линейкой extX в частности.
>значит просто берет на понта на хрена Вы мне здались? денег на Вас я всё-равно не заработаю.
Стоит признать, что здесь вы соврешенно правы. Щас делаю статью об ext4, пришлось хорошенько разобраться в вопросе. Действительно, разработчики ext2/3/4 очень серьезно подошли к устойчивости ФС к сбоям питания, случайным записям и битым секторам. Потом, у e2fsck очень сильная логика. Словом, вероятность успешного восстановления данных после некой ошибки у ФС семейства ext наивысшая. Это их единственное преимущество -- для многих решающее.Из практики могу сказать, что reiserfs ведет себя не менее достойно, но алгоритчмически ext3 сильнее -- мне, видимо, просто не доводилось сталкиваться с действительно серьезеными ошибками.
PS: не забываем, что большинство этих вопросов нивелируется наличием UPS и RAID.
И нельзя не отметить, что в btrfs вопрос устойчивости к сбоям также в числе первых стоит.
>но алгоритчмически ext3 сильнееда ничем она не сильнее, единственное ее "преимущество" (чисто структурное, со всеми вытекающими) - известно расположение инодов на диске, а "логика" так это вообще обзац:
http://www.mail-archive.com/linux-ext4@vger.kernel.org/...
цитата по ссылке: "although ext3 has redundant copies of the superblock (RRedundancy), these copies are never updated after file system creation and hence are not useful. Finally, there are important cases when ext3 violates the journaling semantics, committing or checkpointing invalid transactions."
вы код посмотрите. да, ничего особенного там нет. просто предусмотрена обработка многих ситуаций, при возникновении которых прочие fsck либо честно паникуют, либо не в состоянии что либо сделать.да, все эти последствия вытекают из фиксированного положения таблиц inodes -- гордиться вроде бы нечем. но факт остается фактом -- устойчивость от этого сильно выигрывает.
PS: я не являюсь фанатом или защитником ext2/3/4 -- напротив, всегда утверждал, что это изрядно устаревшие продукты. но сильные стороны у них есть, отрцать это бессмысленно.
мало того, уверен, что ext4 приживется лишь у ленивых и конcервативных и только благодаря легкому апгрейду с ext3, да и то не надолго -- btrfs ее на голову выше по всем параметрам, включая устойчивость к сбоям железа. это уже поняли не только пользователи, но мэйнтейнеры -- судя по очень скорому ее включению в mainline kernel.
>PS: я не являюсь фанатом или защитником ext2/3/4 -- напротив, всегда утверждал,
>что это изрядно устаревшие продукты. но сильные стороны у них есть,
>отрцать это бессмысленно.Ну вот, а меня пинал за констатацию факта и заявлял что дескать у других лучше.Я не злопамятный, но память у меня хорошая ;)
>мало того, уверен, что ext4 приживется лишь у ленивых и конcервативных и
>только благодаря легкому апгрейду с ext3,ИМХО он еще приживется у тех кто юзает дефолты.То есть - у большинства.
>-- btrfs ее на голову выше по всем параметрам, включая устойчивость
>к сбоям железа.На него я возлагаю большие надежды.Это то чего я и жду =).Правда верить на слово - не мой метод.Вот когда его поюзает достаточно народа - будет видно насколько он "сыпуч" не в теории а на практике.Ну и надеюсь что тулзы их комплекта ФС не подкачают - без них даже лучшую ФС использовать страшно.Хороший тул должен быть не хуже ext'овских fsck.
каюсь :)
>каюсь :)Ладно вам, это я так, не со зла :).У вас статьи дельные по анатомии ФС на сайте, весьма познавательно.Спасибо за труд.
>Из практики могу сказать, что reiserfs ведет себя не менее достойноИз практики: вчера у коллеги, после проверки файловой системы на диске (просто запустилась проверка раз в 30 дней, никаких сбоев питания не было.(ноутбук), ситуация штатная) полностью были перебиты права на каталог /usr/bin..... Сталкиваюсь с этим уже второй раз. Ядра разные.
Хотя скорее это проблемы не reiserfs а fsck....
да, fsck они облновляют достаточно активно -- значит есть причины. напишите багрепорт, что ли.подобных случаев я видел примерно одинаково как по ext3, так и по reiserfs. потому и говорю, что ведут они себя сходно.
>Потом, у e2fsck очень сильная логика. Словом, вероятность успешного восстановления данных
>после некой ошибки у ФС семейства ext наивысшая. Это их единственное
>преимущество -- для многих решающее.Ну вот, а меня кто-то за констатацию этого факта в свое время ругал =)
ну виноват, виноват :)полез разбираться, посмотрел -- действительно не плохо дселано.
> ну виноват, виноват :)А, ерунда, мне ваши статьи про ФС нравятся.На русском ничего лучше вообще не попадалось.
>полез разбираться, посмотрел -- действительно не плохо дселано.
Если б там плохо сделали - толпы злых пользователей imho давно бы устроили такой вой что все бы знали что линуксы - это такой глюкатель который норовит угробить данные :).Просто потому что EXTы пользуют более 90% инсталляций (если не ошибаюсь).При этом халтура неизбежно выплывет и многократно икнется.А при таком масштабе использования - писать качественно просто придется.Или закидают тухлыми помидорами, так что не отмоешься.
Стереотипы. Проблемы, связанные с обнулением, датированы 2003 вроде бы годом. Давно уже исправлены. Что касается "памяти не хватило"
> Не осилили документацию.Использую не один год на 10ТБ медиа-архиве.
>Стереотипы. Проблемы, связанные с обнулением, датированы 2003 вроде бы годом.А если верить ченжлогам линуксного кернеля то их остатки добивали явно позже.
Использую 2,5 года на сервер (2 массива 5го уровня)
За это время чего только не было
поочерендно заменял харды в массивах
Растягивал ФС неоднократно
Вырубал питание (не в момент растягивания :)))Вобщем все отлично! Очень доволен. Перешел с ReiserFS. Ну очень доволен!
использую raid5 с XFS уже года 3.
добавлял диски в рейд и растягивал фс, причем на лету :)
сейчас рейд из 5 по 500гб дисков /dev/md0 on /opt type xfs (rw,sunit=256,swidth=1024)
за все время проблем не было, правда 1 раз нарвался на баг, некоторые процессы делающие i/o на xfs переходили в deep sleep. Не помню в каком ядре это исправили.
штуки 4 сервера с raid5 и восемью винтами на 750мб - 1тб.
Ровно и стабильно работают, отдавая до 2 гигабит каждый.
XFS поставлена на сырой md0 без создания раздела.
Больше года - полёт нормальный, проблем не выявлено... :)
Выключения при работе не приводили к повреждению XFS.