Хмутро.
Граждане, а как у нас нынче с надежностью btrfs? А другими тараканами?
А то я в одном месте читаю, что типа мейтейнер ext4 полагает ее
временной мерой, и уже пора переходить на btrfs, а в дебиановской вики
перечислено такое количество тараканов...
Изрядная часть из них - из разряда "тут играть, тут не играть, тут рыбу
заворачивали". Типа, эта функция есть, но чревата потерей данных, так
что лучше не использовать. Компрессию лучше не использовать. dpkg (если
делать рут на btrfs) страшно тормозит, и чинить это никто не будет.
И все это касается в том числе и свежих ядер, в смысле, более свежих,
чем в stable.
Или ну его пока нафиг, и пожить на старой доброй ext4? Задача - ФС под
домашний файловый/бэкапный сервер. 8 TB. Его собственное содержимое
бэкапится, увы, пока нерегулярно. Рейд тоже пока увы. Во-первых,
нетбабла (диск такого объема не три копейки стоит), а во-вторых, в той
машинке быстрый SATA-выход один.
Снапшоты, которыми имелось в виду пользоваться при экспериментах с zfs,
не прижились, самопальные скрипты вокруг rsync на задаче бэкапов дают
лучшую управляемость. Еще хотелось разнесения задач по подтомам, благо
zfs (и btrfs) динамически распределяют под них место, но что-то тоже
практического применения не сложилось.
А вот косой взгляд на инструменты out-of-band deduplication для btrfs
как раз вызывает интерес к оной файловой системе. Поскольку там немало
бэкапов, и порой файлы в них переезжают, эта функциональность
представляется нелишней. Расслабиться на тему "ну и что, что сотню
гигабайт переложили и потрогали, к завтрему перелинкуется" было бы
приятно.