BTRFS на десктопе в 2019

Да что-то работает себе…

Аналогично :( Повода заменить на ZFS всё нет и нет.

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

Жить можно, во всяком случае если с регулярными бекапами. Но если нет особой нужды, то лучше всё же ext4

Если тебя задаёт вопрос «ни с того, ни с сего», она тебе не нужна, это не серебряная пуля.

Очень интересна возможность быстрых снэпшотов. С них восстановить можно?

Очень интересны быстрые снэпшоты. Именно поэтому хочу попробовать

Что восстановить?

Снапшот — не бэкап. Он защищает разве что от кривых рук. Снапшот — часть той же ФС, и если ФС рассыпется, то снапшоты рассыпятся вместе с ней.

Но бэкапы тоже находятся в ФС и, соответственно, часть ее.

Попробуй.

Как в 2013 было готово без RAID56, так и поныне.

Хочешь острых ощущений - bcachefs.

Зато можно сделать снимок, а потом btrfs send | btrfs receive на соседний винт, например. Не прям киллер-фича, но довольно удобно как наколенное решение для бэкапа.

Разве эта тормозная говнофс кому-то нужна?

Можно. Вполне себе киллер-фича. Я так ноут бэкаплю. Дельта улетает за пять минут, а на сервере уже гоняю borg без каких-либо констрейнтов по времени и энергии.

Наверное, верну Btrfs под систему, а то Ext4 не оправдала надежд.

на сервере уже гоняю borg

% borg create -s -p -v --exclude-caches --compression none /media/backup/home::{hostname}-{now} ~
Creating archive at "/media/backup/home::{hostname}-{now}"
------------------------------------------------------------------------------                                         
Archive name: tenshi-2019-01-16T21:44:53
Archive fingerprint: 54751fb9bc53cc9c7322ea47060cdecfc0727422d138053ce2d8926c21e15f18
Time (start): Wed, 2019-01-16 21:44:53
Time (end):   Wed, 2019-01-16 21:45:09
Duration: 15.41 seconds
Number of files: 133225
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:              301.62 GB            301.63 GB            202.26 MB
All archives:               10.24 TB             10.25 TB            343.78 GB

                       Unique chunks         Total chunks
Chunk index:                  457741              7999087
------------------------------------------------------------------------------

Там же кэш есть.

Ну это если у тебя пара мегабайт поменялась.

Уже не работает. Выпилили.

Попробуй держать бекапы на другой ФС? А лучше на другом накопителе. Или даже на другом компе

Наверное, верну Btrfs под систему, а то Ext4 не оправдала надежд

А что не так? Это же варик по умолчанию

Я думал станет быстрее (загрузка системы, её обновления, и т.д.), а нифига, апдейты даже наоборот медленнее накатываться стали

BTRFS на десктопе в 2019

Юзаю на Debian с 2018. Снапшотами не пользуюсь, мне они не сильно удобны. Всё хорошо, всё работает.

BTRFS разве быстрее? Есть же вроде ФС побыстрее... ZFS?

Со сжатием наверное быстрее.

А я наоборот, хотел накатить арчик, и никак не мог определится между ext4 и zfs

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

Есть же вроде ФС побыстрее... ZFS?

Вот точно не ZFS. CoW ФС это вообще не то место, где ищут скорости.

Знаешь, когда это не работает? С образами ВМ. У него меняется mtime и весь твой кэш идёт нафиг. А ФС знает, что поменялось от силы мегабайт сто.

Да и как бы там ни было, отослать уже готовую дельту проще, чем шарашить по файлам бегущим окном, сжатием и ещё чем угодно.

Ежечасные бэкапы — это, конечно, круто, но нерелевантно.

И что же мешает повреждениям возникнуть на другом компе, накопителе, ФС?

Ну ты же знаешь, что бэкапы тоже повреждаются.

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

К RH8 ее можно будет каким-нибудь неподдерживаемым, но надежным спрособом прикрутить?

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

Держать по 3-4 одинаковых бэкапа можно разве что ценных данных, но врядли это будет игор, хентай или горяченькое с Сашей Грей...

Но на десктопе врядли кто-то так делает.

Насколько надёжным?

Как сейчас в 7.6, например. Не все работает, без поддержки, но данные не портит.

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

Вопрос в том, будет ли проект Centos, которому «известны» рх-патчи, компилировать соответствующий модуль btrfs.

С юзерспейсной частью проблем не будет, там ясно, что делать.

Чудовищное решение, на самом деле. В Linux нет современной ФС.

APFS, ReFS — готовы и поддерживаются, ZoL не будет никогда, проект Stratis кажется многообещающим и допускает постепенное внедрение (это большой плюс), но он будет готов лет через пять.

Apple File System does not provide checksums for user data, but does for metadata integrity.[16] It also does not take advantage of byte-addressable non-volatile random-access memory,[17] and does not support compression yet.[4]

Готовность 146%! 😱

ReFS

😁

проект Stratis кажется многообещающим

Ой всё.

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

Вообще не понимаю, что мешает взять .src.rpm, поправить конфиг и скомпилить то, что нужно.

Есть XFS.

на самом деле. В Linux нет современной ФС

Прочитав это, я подумал: это написал анонимус... угадал.

а то Ext4 не оправдала надежд.

Интересно, какие надежды на неё возлагались? Вставание системы раком с No space left on the device с только на половину забитым разделом?

Интересно, какие надежды на неё возлагались?

Например, способность не просрать данные по-тихому.