btrfs как кроссплатформенная замена ntfs

Может, лучше exfat?

У него с устойчивостью к потере питания хуже таки, как и всего семейства FAT. Да, UPS в наличии, а у лаптопа свой акк, но все же, иногда приходится делать powercycle, и тогда - ой.

Да и были прецеденты коррапта данных самсунговским ядерным драйвером, но на флэшках их особо не жаль, они всегда есть где-то еще.

Ну, судя по ченджлогам, winbtrfs умеет все нужные опции вроде сжатия и прочего, так что дерзай, потом нам расскажешь)

Ты, вроде бы, на онтопике btrfs применял? Дефолт? Или крутил что-то?

Меня, в общем-то, больше онтопик интересует. Оффтопик загружается раз в полгода, когда какая-нибудь вендоспецифическая хрень нужна.

Применял ради снапшотов для подстраховки от неудачных апдейтов системы. Когда перешёл с гента на Манжару - надобность в такой подстраховке отпала, так что накатил ext4. Думал, что ext4 быстрее, но нет.

Юзал с такими опциями монтирования:

noatime,max_inline=256,compress=lzo,ssd,discard

Но это на ssd было, на харде, возможно, нужно будет ещё autodefrag заюзать.

winbtrfs не умеет в дефраг, насколько я понял. Ну и мне актуально для nvme ssd, на хардах совсем холодные данные, им на тормоза ntfs.3g пофигу.

Тогда autodefrag не нужен, и для ssd как раз btrfs очень хороша. Только compress-force не включай, а то тормозить будет. Обычного compress достаточно.

WinBtrfs… почти норм. При невыясненных обстоятельствах корраптит раздел и теряет все данные. То ли из-за TRIM, то ли из-за metadata=single.

А когда не корраптит, то работает замечательно. =)

Спасибо, буду пробовать.
А compress вообще имеет смысл какой-то для лучшей целостности данных? Задачи экономить место особо не стоит.

При невыясненных обстоятельствах корраптит раздел и теряет все данные

Давно это было?

Зачем btrfs, когда есть ext? И в оффтопике драйвер более отработанный. Да и устойчивость бтрфс к потере энергии по опыт миф. После блэкаута у меня намертво вешало загрузку монтирование бтрфс-раздела, например.

Полгода-год? назад. WinBtrfs 1.3. С тех пор не тестил.

А compress вообще имеет смысл какой-то для лучшей целостности данных?

На целостность оно никак не влияет, но скорость немного повышает.

Мой десктоп на btrfs пережил десятки внезапных ребутов и выключений, в т.ч. и во время записи, ни разу проблем не было.

Сидите, небось, на протухших «штабильных» ядрах, а потом на файлухи валите всё)))

Спасибо, буду пробовать.

А какой профит, по сравнению с ext2? Не очень понятно.

У меня был печальный опыт с ext4 на Винде :(

с ext4 на Винде

Это то как? Через какую хренть?

для ssd как раз btrfs очень хороша

Смотря с какой точки зрения смотреть.
Write amplificaiton у BTRFS внезапно намного выше, чем можно было бы представить: Выявляем процессы с дисковой активностью в Linux

Чем она на практике хороша для ssd, так это упаковкой хвостов, и тем, что подвезли zstd, который действительно весьма эффективен.
SSD не такие резиновые как вертушки, с btrfs на них места стаёт побольше.

Manjaro, default btrfs, полет нормальный уже пару лет. Но это ноут, который как сервер 24х7.

с btrfs на них места стаёт побольше

Ощутимо больше только если снапшоты юзать.

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

Точно знаю, что некоторые используют btrfs на повседневной основе, потому к ним вопрос - дефолт, не дефолт?

Использую везде. mkfs — умолчания, fstab — только noatime. Никогда ничего не ломалось, разве что один раз после уменьшения ФС появилось предупреждение при проверке, которое не устранялось repair. С внезапными отключениями проблем не было, но иллюзий на этот счёт не питаю, однажды наверняка рассыплется.

Ext2fsd года три назад.

У меня на btrfs не только система, но и директория /home, использую много подтомов и сжатие, полёт нормальный.

Когда форматировал хранение метаданных настроил дублируемым, хранение данных в single.

Но это ноут, который как сервер 24х7

О, я не один такой =)

Когда форматировал хранение метаданных настроил дублируемым, хранение данных в single.

Что дает, чем обусловлено?

SSD не такие резиновые как вертушки, с btrfs на них места стаёт побольше.

У меня меньше 1тб нету, так что наверное все ж резиновые.
Со сжатием я на флэшке игрался, прикольная тема, позволяет упихать в 8гб столько же, сколько на ext4 в 16 влазит.

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

ну не выбрасывать же старье :)

У парагоновского драйвера, судя по всему, все не очень хорошо с ядром, ибо LTS просит:

:: Package ufsd-pro-dkms not found in repositories, trying AUR...
:: разрешение зависимостей...
:: поиск конфликтов между пакетами...
:: ufsd-pro-dkms и ntfs-3g конфликтуют (ntfs-3g). Удалить ntfs-3g? [y/N] y

AUR Packages  (1) ufsd-pro-dkms-9.6.7-1  
Repo Packages (2) linux-lts-4.19.90-1  linux-lts-headers-4.19.90-1  

Размер загрузки из репо:  81.58 МиБ
Размер установки из репо:  165.77 МиБ

:: Приступить к установке? [Y/n]

Что дает

На любой флэш-памяти — ничего.

чем обусловлено

Тараканами, ну 😀

Ощутимо больше только если снапшоты юзать.

Смотря что за ощутимо считать.

root@vaio:/home/aidaho# compsize --one-file-system /
Processed 643260 files, 433183 regular extents (446971 refs), 321160 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       78%       30G          39G          39G
none       100%       25G          25G          25G
lzo         60%      244M         402M         424M
zstd        37%      4.8G          13G          13G

root@optiplex:/home/aidaho# compsize /media/aidaho/armor/Library
Processed 1137973 files, 4391756 regular extents (4480617 refs), 412772 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL       57%      285G         501G         506G
none       100%       23G          23G          26G
zlib        55%       55M          99M          99M
zstd        54%      262G         477G         480G

А что касается большой записи - я за 5 лет только 7% ресурса истратил, мелочи.

Это да, ssd-фобы должны страдать.
Но write amplification это ещё и более медленная запись.

AFL, xfstests, много чего есть. Многие проблемы в Btrfs были найдены именно ими.

А как с поеданием проца у zstd?
Понятно, что проца нынче много, и на десктопе - пусть его жрет, а вот на ноуте это чревато падением автономности...

А как с поеданием проца у zstd?

Если не читать/писать сжимаемые данные высоким битрейтом, то в целом никак.

Так все данные так или иначе сжимаемые, кроме архивов, аудио и видео.

Я слабо представляю себе такой юзкейс где хост пишет сотни Мб/с сжимаемых данных.
Если это какой-то высоконагруженный 1цэ, то его базам можно сделать chattr -c и спать спокойно.

По чтению наиболее затратен холодный старт пк, где сплошь сжимаемые бинарники и конфиги, но и там врядли даже в пике будет 200Мб/c.

Семечки, короче.

Затрахали вы своим RH. Он туда коммитил 10 лет назад,
а потом забил. Ну выкинул он из своего дистра - на
ход поршней это никак не влияет.
https://www.suse.com/c/butter-bei-die-fische/

Вообще, это крайне забавно, как свободные и антипопсовые линуксоиды проявляют свою латентную тоску по Сапогу и мейнстриму наяриванием на телодвижения Ред Хата.

Всем хочется нормального уровня поддержки кода.
А то будет как с reiser4.

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

Это дефолт. metadata=dup, data=single.

Даёт некоторую защиту от того, чтобы первый же битый сектор не сломал тебе всю ФС. Если у тебя случится битый или покоррапченный сектор, и он попадёт в дерево хранения — то ФС можно сразу выкидывать. А поскольку метаданные занимают мало, то их можно и продублировать.

Это дефолт только для HDD, на SSD нужно (не нужно) включать руками.

Да, на SSD такого нет, потому что якобы SSD могут что-то надедуплицировать и толку не будет.

Но тут вроде не про SSD речь шла.

SSD могут что-то надедуплицировать

Вроде эра сандфорсов давно прошла с их странными «оптимизациями»

Но тут вроде не про SSD речь шла.

Как раз про SSD, винты можно оставить и на NTFS. Хотя я так смотрю на все это, и так и не вижу адекватного решения...

А дефолт остался. Поэтому и говорю «якобы».

Немного экспериментов по копированию файла размером 48ГБ внутри одной файловой системы: Samsung 850 EVO + VeraCrypt (примонтировано cryptsetup) + btrfs (default, metadata=dup)

real	1m52,974s
user	0m0,107s
sys	0m26,848s

Samsung PM981 + VeraCrypt (примонтировано cryptsetup) + ntfs-3g

real	6m2,553s
user	0m2,005s
sys	1m4,122s

Результаты у ntfs-3g просто удручающие, не смотря на намного более шустрый диск.

Ext2fsd

Так он же ext4 не алё! Или я чего то не знаю?

Але, в режиме ext3.
Он с тех пор стал ext3fsd, но тоже не сильно жив...