Эдуард Шишкин выступил с критикой Btrfs

> Даже во времена ДОСа были архиваторы. В таких случаях они выручали.

С архиватором нельзя было запустить прямо с дискеты. :)

There are also a lot of ideas from reiserfsv3 and xfs and ext in Btrfs. To me, filesystems are really just a collection of tradeoffs and optimizations for specific goals. We trade CPU for disk IO, or CPU and disk IO for features, and these tradeoffs change as we go.

When designing btrfs we took a big pile of known solutions for filesystem problems, crammed them together, and then fixed up the new problems that resulted. Somehow I missed the scientific magazine step that all the other filesystems have followed, but I'll do what I can to keep improving the FS.

Энтырпрайз? Уахахах, да это ж полный #%^&! Сантехники у штурвала :D

> arj наше фсио!!!!!

lha же. :)

Camel>> При том что Эдуард наглядно показал, что кривую бету пре-альфы макетной реализации в linux впихнули, а нормальную стабильную ФС с выдающимися характеристиками не принимают уже много лет.

Эдуард не учёл, что аналогичных по области применения Reiser4 ФС как собак нерезаных. А аналогов BTRFS в линуксе просто нет. Посему приняли так легко недостаточно обкатанную версию.

Рейзер4 имеет наращиваемую архитектуру, т.е в теории из неё наверно возможно и что нибудь типа zfs соорудить. Я например не слышал о ФС с наращиваемой архитектурой.

Давно последний раз вы видели много файлов размеро 2КБ в ынытырпрайзе?

Шелл-сервер для стопицот разработчиков.

>> пригодно ли оно для настоящего «ынтырпрайз» применения

Давно последний раз вы видели много файлов размеро 2КБ в ынытырпрайзе?

дело даже не в том, что есть некая проблема с малыми файлами, а в том, что если судить по треду, ничего вразумительного Шишкину ответить не смогли, хотя могли бы сказать, что это не баг а фича, и она даёт другие преимущества, и описать эти преимущества. Пока сложилось ощущение, что разработчики бтр-а слабо представляют себе его дизайн - а это странно, по меньшей мере.

И да, обрати внимание, что Шишкин работает в RedHat, т.е надо ждать рейзер4 в ядре, и возможно даже в качестве умолчальной ФС ;-)

> И да, обрати внимание, что Шишкин работает в RedHat, т.е надо ждать рейзер4 в ядре, и возможно даже в качестве умолчальной ФС ;-)

Ну, если контора уровня RedHat займётся допиливанием рейзера, тогда у него действительно есть шансы.

lha же. :)

точно, точно и aidstest.exe туда же...

>btrfs + compress

+ compress

Зачем? О_о

К сожалению, там только начало.

А если почитать переписку, что Крис далее в общем признаёт, что проблема достаточно серьёзная и простых решений как-бы не имеет.

>Столь низкая эффективность использования дискового пространства, похоже, является фундаментальным свойством тех алгоритмов, которые положены в основу Btrfs. А именно, Btrfs пытается хранить блоки переменного размера («inline extents», xattr, и тд) в структуре данных «B-tree». Однако B-tree предоставляет гарантии эффективного использования памяти лишь для блоков постоянного размера.

Мысль интересная, но это только предположение. Нужно доказательство а не эмпирические доводы. ХЗ почему Шишкин такие результаты намерил, в чем суть проблемы пока не ясно. BTRFS вроде как активно разрабатывают, так что скорее всего эту засаду пофиксят.

А развести истерику на тему «закопать» много ума не надо.

> Однако B-tree предоставляет гарантии эффективного использования памяти лишь для блоков постоянного размера.

Если я не ошибаюсь XFS также использует B-деревья для хранения своих внутренних структур и также экстенты переменного размера, как же она работает эффективно? Значит, либо она делает что-то по-другому, либо Шишкин неправ.

> Ну а все-таки? Что самое важное?

Вы реально верите в one-size-fits-all? Что есть что-то самое важное *для всех*?

Одним из бывших девелоперов ZFS, строго говоря. Переставшей быть таковой где-то году в 2004 или даже еще раньше.

Иными словами, она присутствовала в группе разработчиков в то время, когда закладывались (и, предположительно, обсуждались) архитектурные основы zfs. И я рискну считать, что она имеет более глубокое представление об архитектуре (и, в том числе, налагаемых ей ограничениях), чем какой-то непонятный анонимус.

Btrfs will be the default file system on Linux within two years.

Дык я об этом же собственно и говорю. Пару лет еще до дефолтного состояния. Если не больше.

Один год с момента предсказания уже прошел. И лично я был несколько удивлен, увидев недавно на форониксе вполне приличные результаты btrfs. Я ожидал, что она будет прогрессировать медленнее.

Иногда (и/или для кого-то) выигрыш чуть больше погрешности измерений по одному показателю вполне стоит проигрыша по другому на порядок.

Намекаешь на возможность удаления устройств?

Нед. Это называется «общие соображения». Это даже не про фс. Просто (эээ, как бы вам обйаснить...), во-первых, производительность – величина многомерная. А, во-вторых, предпочтения одних компонент другим (как и вообще любые ценностные суждения, как нас учит Людвиг фон Мизес) принципиально субъективны.

>> И, да, вот например до сих пор не пофиксенный ZFS'ный багрепорт, открытый в 2003 году. И будет ли он вообще пофиксен – большой вопрос. http://bugs.opensolaris.org/view_bug.do?bug_id=4852783

Гыы, как в воду глядел.

«Темна вода во облацех»©, ога.

Что именно у тебя большой вопрос вызывает?

Сама возможность эффективной реализации переноса^Wперепаковки объектов в фс, основанной на слэбах и при том без обратных ссылок.

В btrfs то знаешь как это работает? Примерно так же, как упаковка мелких файлов.

То, как оно работает в тестовой версии – не показательно. Важно, что сама архитектура более приспособлена для этого.

Так что пока можно считать, что эта возможность заявлена, но как следует не работает. В том виде, в каком она «работает», можно считать, что ее нету.

В отличие от zfs, в которой она вообще не заявлена и скорее всего не появится никогда.

> Скоро не будет вашей Btrfs. У Oracle есть Solaris и ZFS. На допиливание кривых ляликсовых конкурирующих поделок они клали большой ignore.

Есть мнение, что ораклу не нужен солярис. Им вообще не нужна *своя* ос, им надо чтобы (1) ос не контролировалась конкурентами и (2) чтоб не надо было тащить самим всю цену разработки и поддержки ос. Линукс этим пунктам удовлетворяет, в отличие от соляры.

> Мысль интересная, но это только предположение. Нужно доказательство а не эмпирические доводы.

Точно, нужно доказательство, что Btrfs ведет себя хоть сколько-нибудь вменяемо на любой нагрузке. Предоставить доказательство вменяемости авторы Btrfs не в состоянии (судя по переписка на lkml). Более того, Крис вообще не заморачивается насчет корректности, и проповедует чисто эмпирический подход. Цитаты в комментах выше.

> Линуксовый порт, говорят, получился менее стабильный.

Откуда дровишки? Я помню, что в википедии что-то писали, что вроде как RH не хочет включать xfs якобы по соображениям стабильности. Но в приводимой там ссылке на багзиллу стабильность не упоминалась вообще, и у меня по прочтении создалось впечатление, что скорее RH хочет срубить дополнительные бабки за поддержку xfs.

>> А это вообще как-нибудь лечится?

Похоже, что нет. Опция barrier никак не влияет на ситуацию.

Барьеры тут как бы не при чем. Это называется unwritten extent support, и в новых версиях xfsprogs его выключить нельзя.

Странная фича, по-моему. Можно было бы хоть что-то внутри файла оставлять, как делают другие ФС. Суровый энтерпрайз суров.

Ничего странного, это связано с безопасностью. Нет никаких гарантий, что запись будет происходить в тот же экстент, в котором находятся старые данные, запись может происходить и в экстент, в котором когда-то были чужие данные. Поэтому *до завершения записи* экстент помечается специальным образом, и при следующем монтировании грязной фс все недозаписанные экстенты стираются. Если этого не делать, то может быть утечка потенциально чувствительных данных.

> Нужно доказательство

Ну а ценность доказательства невменяемости, сам понимаешь, околонулевая. Крис в очередной раз вхачит свои чудо-эвристики в коде Btrfs - и доказательство теряет актуальность, не смотря на то, что по сути ничего не исправлено.

Откуда дровишки?

Из леса, вестимо.

Я помню, что в википедии что-то писали, что вроде как RH не хочет включать xfs якобы по соображениям стабильности. Но в приводимой там ссылке на багзиллу стабильность не упоминалась вообще, и у меня по прочтении создалось впечатление, что скорее RH хочет срубить дополнительные бабки за поддержку xfs.

«Срубить бабки»... Для коммерческой поддержки продукта foo нужен специалист по продукту foo, которому нужно платить з/п. Специалиста по XFS уровня его разработчика ещё нужно притащить в контору, и, желательно, не одного. Вот просто для того, чтобы опцию «xfs» можно было добавить в инсталлятор RHEL, нужно вбухать много денег. Это ведь энтерпрайз, а не генту какая-нибудь.

Почему-то после литра пива эта новость вызвала безудержный смех. Да здравствую холивары на уровне девелоперс!

> «Срубить бабки»... Для коммерческой поддержки продукта foo нужен специалист по продукту foo, которому нужно платить з/п. Специалиста по XFS уровня его разработчика ещё нужно притащить в контору, и, желательно, не одного. Вот просто для того, чтобы опцию «xfs» можно было добавить в инсталлятор RHEL, нужно вбухать много денег. Это ведь энтерпрайз, а не генту какая-нибудь.

Дыг естественно. Даже независимо от того, вбухивает ли RH кучу денег во что-то, или нет, я ни коим образом не против того, чтоб они на этом зарабатывали. Просто не надо путать «мы не дадим вам это без дополнительныы бабок» и «мы не дадим вам это, потому что это не стабильно».

>Скоро корень все перенесут на SSD, и скорость рейзера потеряет всякую актуальность.

Хохма заключается в том, что производительность reiser4 на ssd отвратительна, покуда не замаскированы все fsync.

>>не замечал таких вещей.

Т.е. срочно в ядро? Популярное подобие аргумента.

> а шишкин пусть лучше пилит его вместо срача в троллерассылке :)

Срачь в рассылке это часть процесса разработки ;)

> Есть мнение, что ораклу не нужен солярис. Им вообще не нужна *своя* ос, им надо чтобы (1) ос не контролировалась конкурентами и (2) чтоб не надо было тащить самим всю цену разработки и поддержки ос. Линукс этим пунктам удовлетворяет, в отличие от соляры.

И еще, если я правильно помню летом 98 года оракл был второй компанией (первая – IBM), объявившей о поддержке линукса. Ну или если не второй, то точно в пятерке.

> ХЗ почему Шишкин такие результаты намерил, в чем суть проблемы пока не ясно.

Суть проблемы ясна и популярно изложена. COW-friendly деревья описаны только на основе классических B-деревьев Байерса, которые не могут работать с рекордсами переменной длины (иначе пипец в виде обвальной внутренней фрагментации). А Крис Мейсон захотел преимуществ Reiserfs. Он изменил балансировку и тупо впендюрил в свою Btrfs фичу рейзера под названием tail packing. И случился облом, потому что Reiserfs хотя и работает с рекордсами переменной длины, но не использует B-деревья Байерса и не допускает (пока что) специфической балансировки «сверху вниз», которая так необходима COW-friendly деревьям.

> Суть проблемы ясна и популярно изложена. COW-friendly деревья описаны только на основе классических B-деревьев Байерса, которые не могут работать с рекордсами переменной длины (иначе пипец в виде обвальной внутренней фрагментации). А Крис Мейсон захотел преимуществ Reiserfs. Он изменил балансировку и тупо впендюрил в свою Btrfs фичу рейзера под названием tail packing.

Во-первых, там не только концы файлов, там и inodes и другие значения переменной длины в листьях (только в листьях, в других узлах значения только постоянного размера) есть.

Во-вторых, в той дискуссии один из персонажей приводит такой аргумент:

«I've studied modified B-trees quite a lot and know enough to be sure that they are quite robust when you modify them in all sorts of ways.

Moreover, you are incorrect to say there's an intrinsic algorithmic problem with variable-length records. It is not true; if Knuth said so, Knuth was mistaken.

This is easily shown by modelling variable-length records (key -> string) as a range of fixed length records ([key,index] -> byte) and apply the standard B-tree algorithms to that, which guarantees algorithm properties such as space utilisation and time; then you can substitute a „compressed“ representation of contiguous index runs, which amounts to nothing more than just storing the strings (split where the algorithm says to do so) and endpoint indexes , and because this compression does not expand (in any way that matters), classic algorithmic properties are still guaranteed.» http://lkml.org/lkml/2010/6/18/199

На первый взгляд достаточно логично, и, что характерно, Шишкин на этот аргумент не счел нужным ответить.

> ZFS вон в те же 659MiB 284 тычячи смогла упаковать, и это с дупликацией метаданных и местом для функциониования CoW.

А вот кстати интересно, в свете использования слабов, сколько файлов размером 2049 байт она туда упакует?

шишкин и мэйсон - близнецы-братья

40кб. калькулятор что ли купи

> This is easily shown by modelling variable-length records (key -> string) as a range of fixed length records ([key,index] -> byte) and apply the standard B-tree algorithms to that

А это не приводит к взрывному росту накладных расходов и высоты дерева?

>> This is easily shown by modelling variable-length records (key -> string) as a range of fixed length records ([key,index] -> byte) and apply the standard B-tree algorithms to that

А это не приводит к взрывному росту накладных расходов и высоты дерева?

Вряд ли. Замена одного байта строки на один байт строки плюс скажем два байта плюс еще ключ для каждого байта ведет к увеличению объема данных скажем раз в десять (скорее даже меньше). «Взрывным» я бы скорее назвал экспоненциальный рост, но тут его нет.

> Замена одного байта строки на один байт строки плюс скажем два байта плюс еще ключ для каждого байта ведет к увеличению объема данных скажем раз в десять

А, ну это мелочь, конечно. Подумаешь, на байт полезных данных приходится несколько байт служебных %) Главное - рост не экспоненциальный.

> А, ну это мелочь, конечно. Подумаешь, на байт полезных данных приходится несколько байт служебных %) Главное - рост не экспоненциальный.

С точки зрения анализа характеристик алгоритма, такой рост действительно не важен. Речь не идет о том, чтобы применять эту трансформацию в реальной файловой системе, если вы вдруг не поняли. Речь о том, что не очевидно, что записи переменных размеров в листьях радикально ухудшают поведение btree.

Для тех, кто не знает: Шишкин - разработчик Btrfs, аффилированый компанией Red Hat. В частности, он автор кода поддержки Btrfs в grub-0.97. На основе его патчей Colin Watson накатил поддержку Btrfs на grub-2.

> А это не приводит к взрывному росту накладных расходов и высоты дерева?

И, кстати, а переход от гигабайтного винта к терабайтному, с пропорциональным увеличением размера dataset в тысячу раз, не приводит «к взрывному росту накладных расходов и высоты дерева»?

Какие винты не сояли бы на десктопе но через какое-то время приходится балансировать на нескольких свободных гигах. Размер свободного пространства почти константа. И если несколько сохранённых на btrfs html страниц с картинками отожрут половину оставшегося места, то в топку такие ФС - ext3-4 наше всё.

> Вы реально верите в one-size-fits-all? Что есть что-то самое важное *для всех*?

Вы, по-моему, начинаете троллить. Я этого не говорил, это вы за меня додумали. У меня есть своя позиция на этот счет, и задавая вопрос о том, что же самое важное для файловой системы в 2010 году я рассчитывал получить ответ о вашей точке зрения - что важно для вас, поскольку очевидно, что никакого универсального ответа на этот вопрос нет. Но, похоже, у вас таковой нет. Или есть?

Иными словами, она присутствовала в группе разработчиков в то время, когда закладывались (и, предположительно, обсуждались) архитектурные основы zfs. И я рискну считать, что она имеет более глубокое представление об архитектуре (и, в том числе, налагаемых ей ограничениях), чем какой-то непонятный анонимус.

Рискуйте. Только вот вы ошибетесь, рискуя, так же, как и ошибается в своей статье она и вводит своей ошибкой в заблуждение вас и остальных читателей. Не знаю, почему она не удосужилась в 2009 году заглянуть в код, чтобы увидеть, что ее представления капитально устарели. Боится, видимо, что увидит там что-нибудь лишнее.

Один год с момента предсказания уже прошел. И лично я был несколько удивлен, увидев недавно на форониксе вполне приличные результаты btrfs. Я ожидал, что она будет прогрессировать медленнее.

Correct > Fast. Для файловой системы корректность работы заявленных операций должна быть первым приоритетом. Впрочем, как и для любой другой программной системы. Потому как неверный результат не имеет особой ценности, вне зависимости от скорости его получения

Сама возможность эффективной реализации переноса^Wперепаковки объектов в фс, основанной на слэбах и при том без обратных ссылок.

Вы, как минимум, заблуждаетесь насчет слабов вслед за Хенсон. Ну и насчет возможности переноса блоков между устройствами - тоже.

То, как оно работает в тестовой версии – не показательно.

Еще как показательно. Если в тестовой версии она не справляется с удалением диска в самых простых ситуациях, то это еще как показательно.

Важно, что сама архитектура более приспособлена для этого.

Надо полагать, вы понимаете, как именно она приспособлена. Не объясните в двух словах?

Так что пока можно считать, что эта возможность заявлена, но как следует не работает. В том виде, в каком она «работает», можно считать, что ее нету.

В отличие от zfs, в которой она вообще не заявлена и скорее всего не появится никогда.

Ну здрасьте. Вы ж сами ссылку RFE приводили. Состояние видели? Последнее обновление там тоже не в 2003 году. Хотите - можете подписаться на изменения, там ссылочка внизу есть.

А вот как работает удаление устройства в btrfs.

Есть файловая система btrfs, состоящая из трех дисков по одному гигабайту.

В ней было создано 2457 файлов по 1MiB, прежде, чем кончилось место.

root@siduxbox:~# ls /mnt | wc -l
2457
root@siduxbox:~# df -k /mnt
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdc               3145728   2527560    403968  87% /mnt
root@siduxbox:~# btrfs device delete /dev/sda /mnt
ERROR: error removing the device '/dev/sda'

Как видите, попытка удаления диска в таком состоянии не была успешной, что, впрочем, ожидаемо.

Затем файлы с четными номерами были удалены:

root@siduxbox:~# rm /mnt/file*[02468]
root@siduxbox:~# df -k /mnt
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdc               3145728   1267936   1662208  44% /mnt
root@siduxbox:~# ls /mnt | wc -l
1228

Как видите, доступное место больше размера одного диска, соответственно, можно ожидать, что попытка удаления диска должна быть успешной. Смотрим:

root@siduxbox:~# btrfs device delete /dev/sda /mnt

Message from syslogd@siduxbox at Jun 25 21:32:46 ...
 kernel:[ 1295.710877] ------------[ cut here ]------------

Message from syslogd@siduxbox at Jun 25 21:32:46 ...
 kernel:[ 1295.710882] invalid opcode: 0000 [#1] PREEMPT SMP 

Message from syslogd@siduxbox at Jun 25 21:32:46 ...
 kernel:[ 1295.710975] Stack:

Message from syslogd@siduxbox at Jun 25 21:32:46 ...
 kernel:[ 1295.710984] Call Trace:
Segmentation fault
root@siduxbox:~# 

Чудесная такая диагностика, не правда ли?

Вот что показывает btrfs-show:

root@siduxbox:~# btrfs-show
Label: none  uuid: 9975d400-3a51-4dcd-b0d3-7f30ef45114d
	Total devices 3 FS bytes used 1.20GB
	devid    4 size 1.00GB used 819.00MB path /dev/sda
	devid    2 size 1.00GB used 929.38MB path /dev/sdb
	devid    3 size 1.00GB used 929.38MB path /dev/sdc

Btrfs Btrfs v0.19

То есть диск где был, там и остался. Так что работает удаление пока также, как и упаковка двухкилобайтных файлов, то есть - толком не работает.

Хотя надо признать, что когда из пустой ФС удаляешь диск, он таки удаляется, и даже размер доступного пространства уменьшается. Год назад оно не уменьшалось :-)

>Вот кстати маленькое предсказание от одного из девелоперов ZFS, сделанное в июле 2009: «Btrfs will be the default file system on Linux within two years. Btrfs as a project won't (and can't, at this point) be canceled by Oracle. If all the intellectual property issues are worked out (a big if), ZFS will be ported to Linux, but it will have less than a few percent of the installed base of btrfs.» http://lwn.net/Articles/342892/

Валери Аврора (до замужества Вэл Хэнсон) - безнадёжная дура. Я не знаю, чем она занималась в ZFS-команде. Возможно, её взяли туда для того, чтобы писать подобные хвалебные оды ZFS. Не стоит воспринимать её статьи всерьёз.

> Валери Аврора (до замужества Вэл Хэнсон) - безнадёжная дура.

Слышать аргументы ad hominem от анонимуса – это забавно, да. :)

> я рассчитывал получить ответ о вашей точке зрения - что важно для вас,

У меня нет желания сейчас расписывать мою точку зрения. Писать подробно слишком долго, в том числе и потому что для разных целей сравнительная важность фич разная. А писать коротко – не имеет смысла.

Рискуйте. Только вот вы ошибетесь

Может быть. Но пока что это голословное утверждение от непонятного анонимуса. Может быть вы будете так добры, и укажете, в чем конкретно она ошибается (и вводит в заблуждение [...])?

Один год с момента предсказания уже прошел. И лично я был несколько удивлен, увидев недавно на форониксе вполне приличные результаты btrfs. Я ожидал, что она будет прогрессировать медленнее.

Correct > Fast.

Ну, я скорее склонен согласиться с этим для большинства случаев, да. Но не для всех. При определенных обстоятельствах, я готов довольствоваться некорректным поведением в некоторых случаях (и при выолнении некоторых условиях) если этой ценой я могу получить преимущество в чем-то другом. И похоже я не один такой: http://lwn.net/Articles/393527/ http://lwn.net/Articles/393770/ . Так что, опять, one size doesn't fit all.

Потому как неверный результат не имеет особой ценности, вне зависимости от скорости его получения

Я вам (или же не вам, вы все на одно лицо :) ) уже сообщал, что все ценностные суждения субъективны. И из того, что конкретный результат в конкретных обстоятельствах не имеет *для вас* ценности, еще не следует, что этот результат обязательно не будет иметь ценности для другого лица (или возможно даже для вас в других обстоятельствах).

Надо полагать, вы понимаете, как именно она приспособлена. Не объясните в двух словах?

Насколько я понимаю, наличие обратных ссылок и отсутствие необходимости искать свободные ячейки в слэбе нужного размера несколько облегчают процесс переноса, нет? Впрочем, я признаю, что об архитектуре ZFS я знаю только со слов Авроры/Хенсон, и если вдруг окажется, что ZFS повсюду использует бэкреференсы и не использует слэбов, то тогда я был неправ, да.

Вы, как минимум, заблуждаетесь насчет слабов вслед за Хенсон. Ну и насчет возможности переноса блоков между устройствами - тоже.

Ну здрасьте. Вы ж сами ссылку RFE приводили. Состояние видели? Последнее обновление там тоже не в 2003 году. Хотите - можете подписаться на изменения, там ссылочка внизу есть.

Возможно заблуждаюсь. И, да, я видел состояние. Конкретно, я видел, что по прошествии 7 лет (из которых, сколько, 3 года уже? система считается стабильной) состояние не fixed.

Хотя надо признать, что когда из пустой ФС удаляешь диск, он таки удаляется, и даже размер доступного пространства уменьшается. Год назад оно не уменьшалось :-)

Интересно, вы сильно удивитесь, если вдруг, скажем, через год диск будет удаляться не только из пустой фс? Лично я – не очень.

ZFS вон в те же 659MiB 284 тычячи смогла упаковать, и это с дупликацией метаданных и местом для функциониования CoW

А вот кстати интересно, в свете использования слабов, сколько файлов размером 2049 байт она туда упакует?

ZFS ЖГЕТ!!

Решил таки проверить с файлами по 2049 байт...

Итак: раздел размером 1031903 секторов. Сначала попробовал с 2048-байтными файлами, получилось 215250 файла, 0.83438075 от размера раздела. Дальше zfs отжог:

$ rm /test/1
rm: /test/1 not removed: No space left on device

Вот это я понимаю, Ъ® Ынтырпрайз™ стейбилити! Пришлось переформатировать.

Итого результаты на данный момент:
2048 байт 215250 файлов 0.83438075
2049 байт 175740 файлов 0.68155944
4097 байт 101068 файлов 0.7837378

плагины же, мальчик.

>после чего fsck больше не смог ее починить даже с rebuild-fs

ЧТО нужно сделать, чтобы даже билдфс не помог?

единственный минус рейзер4 - невозможность нормально оторвать журнал и принудительную синхронизацию. без них бы она была бы в разы быстрее

ссд сам по себе отвратителен, корень на нем делать нельзя ни при какой фс, либо все принудительно вешать в память, что тоже не особо гуд. да и живет не больше года, особенно если писать часто, так что извините, мы как нибудь рейдами по старинке. тем более что рейд в 4 диска по цене и выйдет как такой же ссд

у вас в каждом комментарии «бы», «я считаю», «есть мнение», «скорее всего» и тд. пройдите пожалуйста вон из треда

>Рейзер4 имеет наращиваемую архитектуру, т.е в теории из неё наверно возможно и что нибудь типа zfs соорудить. Я например не слышал о ФС с наращиваемой архитектурой.

Я ржал минут пять. Ну ты отжёг. Ты хоть вики по бтрФС читал? Знаешь её основную направленность?