> Не просто "более-менее сошло на нет", а сошло на нет напрочь. Это отлично, но сколько лет это чинили? Да и из интересного в XFS разве что структура при которой оно хорошо работает на нескольких дисках с большими файлами. В остальном ФС как ФС, без каких-то гигантских преимуществ.
> Во всяком случае, после этого жалоб не видел ни в интернете, ни
> живьём - был случай плотно полюбоваться на xfs, умирающую по причине
> периодических отказов диска из-за хренового БП.
Мне тоже после 2.6.28 такое не попадалось - наверное более-менее дожали.
> расхождение в пределах 10-20 процентов с ext4, и не всегда в
> пользу последней (удаление на xfs быстрее, iirc).
У меня до сих пор есть несколько томов в XFS и мне в целом не особо нравится как они работают. Если не лениво - попробуй забенчить например получение полной иерархии (обход директорий и получение списка файлов) на холодную для ext4 и xfs.
Это разумеется надо делать на холодную для каждой ФС (записали файлы - ребут - обход иерархии) и никуда не выводить весь список (чтобы IO и рендеринг от большого списка нигде не клинило). Есть ощущение что xfs на холодную как-то довольно неспешно делает обход vs остальные. Очевидный юзкейс где это может анноить - поиск по вилдкардам в mc, например. На горячую конечно все шустро, но это не заслуга ФС.
> RAID, где она себя показывает круче всего.
Ну да, он с его allocation groups заточен на то чтобы его на несколько дисков раскладывали. Если охота работать с большими файлами и на RAID - вариант. Но это как-то не мои типовые юзкейсы. А например как оно выдерживает несколько иерархий линуксного кернела мне не нравится - на холодную оглавление как-то долго обходится.
> Экзотика - ну да ладно, может пригодиться. В любом случае не серверная
> и не десктопная ФС получается.
Еще не врут про неубиваемость (насколько это понятие применимо для классики с журналом только метаданных). Но в остальном - серая мышка. Единственное разумное что приходит - ФС для винча прицепленного к роутеру со слабым процом и подобные странноватые применения.
> успела пол-файла записать (в смысле вызова write), а потом система умерла.
Если программа не атомарно пишет файл и потом не может это прочитать - это продолб программы и за это спрос с авторов. А если прога сделала 1 большой write на весь файл и файлуха при этом сделала ни два ни полтора - это уже предъявы к файлухе.
> Что, собственно, в большинстве случаев би будет происходить. Попасть в
> промежуток, когда write() все прошли и файл консистентен, но еще (частично)
> не записан на диск - это суметь надо.
По идее достаточно сделать 1 большой write() со стороны программы, переписывающий весь файл или его заметный кусок, а потом нарваться на крах, когда это стало по факту выдавливаться на блины? В результате получится файл который ни туда ни сюда. Хотя программа со своей стороны все нормально сделала. Если не считать нормальным адские костылищи, типа записи в темпарь и ренейм, что почем зря гадит фрагментацией и заметно усложняет код. И является гнусным хаком для компенсации непотребного поведения ФС на уровне приложений. Хотя по идее им бы вообще про журналирование знать не следовало.
> Дык. И это не про журналирование вообще.
Снапшоты как таковые в нормальном виде - некое логическое доразвитие неразрушающего однократного журналирования (CoW и все что подобное по смыслу). Их можно конечно делать и иначе, но получается дрянь. В случае CoW все необходимое для снапшота - уже есть, а сама механика подразумевает легкое и беспроблемное обеспечение сохранности снапшота. Это, в паре с скоростью записи близкой к скорости совсем без журнала, при эффекте близком к полному журналированию настолько жирный и очевидный плюс что большинство новых дизайнов ФС - пытаются делать как-то вот так в основном. Бонусом такие дизайны лучше для флешовых носителей - read-patch-write со стороны фс они не любят, поскольку очень маловероятно что это совпадет с блоками флеша и в результате получится усиление протирания флеша.
> (а он и не должен) то старого доброго "переименовал - создал
> новое - прибил старое" достаточно,
Со своей стороны я считаю это у...щным application layer костылем недожурналу. Этот подход должен умереть - программы не должны делать работу ФС без сильной причины. Я знаю только 2 сильные причины: БД и CoW диски виртуалок, которые могут иметь какие-то свои очень кастомные пожелания по поводу того чтобы ФС была для них почти интерфейсом к блочному уровню, с минимумом помех. Чисто блочные девайсы лучше - но их неудобно админить.
> Но да - согласен, снапшоты на уровне ФС - приятно и удобно.
Бонусом я еще считаю крайне у..щным когда программы вынуждены заниматься левым oнaнизмoм усложняющих их код, для компенсации неспособности ФС нормально журналировать.
