Файловая система для пользовательских данных

Btrfs

ntfs

Очень толсто, ntfs намбер ван по просиранию всего чего можно. Хотя нет, намбер ван hfs. Вы видимо ей не пользовались никогда.

С нее хотя бы восстановить что-то можно в отличие от других...

Ну например, хранила бы контрольные суммы файлов

ZFS

dd if=/dev/zero of=BFS count=1 bs=200M
mkfs.btrfs BFS

Монтируем, создаем текстовы файл, с текстом LINUXORGRU. Отмонтируем.

Открываем в хекседиторе и меняем все LINUXORGRU на LINUXORG11. ФС убита

btrfs check --repair BFS
enabling repair mode
checksum verify failed on 30605312 found B9AD9628 wanted 4DF4582C
checksum verify failed on 30605312 found B9AD9628 wanted 4DF4582C
checksum verify failed on 30605312 found B9AD9628 wanted 4DF4582C
checksum verify failed on 30605312 found B9AD9628 wanted 4DF4582C
Csum didn't match
ERROR: cannot open file system

- У меня друг сервер уронил.
- Он что, хакер?
- Мудак он!

Намёк понятен, думаю.

ntfs
С нее хотя бы восстановить что-то можно в отличие от других...

Я как-то восстановил случайно отформатированный раздел с помощью TestDisk. Там была ext4 с данными на 900 ГБ, префиксы вайна, референсы для 3D графики, работы в Blender... всё было там. У меня на душе было словно отец помер. Я мысленно попрощался с данными и решил попробовать просканировать через TestDisk в надежде хоть что-то вернуть из небытия. Хотя раньше у меня ничего не получалось.

И вот, о, чудо! Мне повезло и он восстановил этот раздел с прежней структурой папок и файлов. Радости не было предела.

Вот так я вернул 99% данных.

Че ты ляпаешь? Я повредил 1 файл, почему ФС не монтируется? Почему не чинится?

Действительно, без ошибок. Вот такое в dmesg сыпет только

[330135.681044] BTRFS warning (device loop1): loop1 checksum verify failed on 30408704 wanted C23EC5B8 found 9E66D431 level 0
[330135.681533] BTRFS info (device loop1): read error corrected: ino 0 off 30408704 (dev /dev/loop1 sector 75776)
[330135.681594] BTRFS info (device loop1): read error corrected: ino 0 off 30412800 (dev /dev/loop1 sector 75784)
[330135.681622] BTRFS info (device loop1): read error corrected: ino 0 off 30416896 (dev /dev/loop1 sector 75792)
[330135.681645] BTRFS info (device loop1): read error corrected: ino 0 off 30420992 (dev /dev/loop1 sector 75800)

сейчас с ext4 попробую

Тебе повезло, я в такой ситуации потерял ~80%. После этого я не доверяю ФС, только физическим бекапам на другой диск...

почему

Я же написал причину выше.

Фс кстати стала как была. После замены всех 10 включений на разные (что-то фантастично что вообще все копии утеряны) ей действительно поплохело, как это починить?

Что-то ей очень поплохело, ничего не восстановить совсем.

Правда она монтируется в режиме raid6, да? Или нет? С 1 диском? Рейды склонны рассыпаться, когда утеряно слишком много данных. В данном примере и восстанавливать нечего.

В данном примере и восстанавливать нечего.

Ок, но ведь служебная часть не пострадала. Почему просто не заблеклистить файл?

Намёк понятен, думаю.

Файловая система сломалась от повреждения двух байт. Файловая система не должна ломаться от повреждения двух байт. Если файловая система ломается от повреждения двух байт — это херовая файловая система.

Два байта могут повредится и без мудаков-хакеров.

Намёк понятен, думаю.

Это ты про ext4 или btrfs?

сейчас с ext4 попробую

Ждем результаты теста.

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

А что с btrfs?

Повреди два байта в суперблоке любой ФС и посмотри что получится.

Всё нормально, битый файл никто не заметил. Он был в 1 экземпляре Мне это встречалось и в жизни, как с ntfs, так и с ext4, причём, в смарте может ничего и не быть, т.е. вроде как всё ок. Память не склонна флипать биты, если что (котя мало ли космические лучи, всякое бывает, только почему-то на файлах которые давно не открывались).

Btrfs умерла после порчи всех копий файла, наверное её можно только в рейде на нескольких дисках держать.

[332575.675130] BTRFS info (device loop1): disk space caching is enabled
[332575.675132] BTRFS info (device loop1): has skinny extents
[332575.681109] BTRFS warning (device loop1): loop1 checksum verify failed on 30408704 wanted C23EC5B8 found 9E66D431 level 0
[332575.681466] BTRFS warning (device loop1): loop1 checksum verify failed on 30408704 wanted C23EC5B8 found 30107767 level 0
[332575.681488] BTRFS warning (device loop1): failed to read fs tree: -5
[332575.687660] BTRFS error (device loop1): open_ctree failed

restore выдаёт

checksum verify failed on 30408704 found 9E66D431 wanted C23EC5B8
checksum verify failed on 30408704 found 9E66D431 wanted C23EC5B8
checksum verify failed on 30408704 found 30107767 wanted C23EC5B8
checksum verify failed on 30408704 found 9E66D431 wanted C23EC5B8
Csum didn't match
Could not open root, trying backup super
checksum verify failed on 30408704 found 9E66D431 wanted C23EC5B8
checksum verify failed on 30408704 found 9E66D431 wanted C23EC5B8
checksum verify failed on 30408704 found 30107767 wanted C23EC5B8
checksum verify failed on 30408704 found 9E66D431 wanted C23EC5B8
Csum didn't match
Could not open root, trying backup super
ERROR: superblock bytenr 274877906944 is larger than device size 1073741824
Could not open root, trying backup super

остаётся вариант с btrfs-find-root и передать вручную, но там нечего ловить она полностью мертва

Superblock thinks the generation is 11
Superblock thinks the level is 0
Found tree root at 30441472 gen 11 level 0

Btrfs умерла

Конечно, ты же ей дерево метаданных сломал.

А каким боком повреждение файла затронуло метаданные? Разве метаданные не служебное для ФС?

Слушай, а можешь это провернуть с reiserfs и xfs?

В Btrfs файлы до определённого размера упаковываются в дерево метаданных.

До какого размера, например?

Не помню. По умолчанию до 4 Кб вроде.

Вот что пишут на «заборе»

ext4 is the best out there in terms of being resistant to failure when you are expecting the failure to happen. XFS is about as resilient as ext4, but doesn't have the same amount of history and tools available as the ext series. ZFS and BTRFS are only more robust when you have multiple disks involved.

Reliability with a file system isn't typically a matter of whether it can seamlessly survive an incident, it's more about whether there are adequate recovery tools available when such an incident occurs.

There is no filesystem that I am aware of that will self-repair when using a single non-RAID disk without user intervention.

Ожидаемо.

Так вроде же запасные копии суперблока хранятся.

reiserfs 1 замена прошла бесследно, ничего не сказала нигде, файл открылся из дальнего блока видимо. Но данные вообще выглядят интересно, вместо HELLOLOR на диске HELLHELLOLOR. Замена второго... Ну, портит файл, да. Как и ожидалось. Hammer2 интересно потыкать было бы, только там от 40 гб ей надо по-моему.

xfs аналогично умолчательной ext4, без приключений.

Почему, у btrfs вполне получается. Пока все суперблоки не сдохнут, да? Интересно, их можно бэкапить? У ext4 вроде можно даже на другом устройстве держать, и журнал на третьем.

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

Хочу поиграться с рейдом, но это виртуалку наверно наворачивать надо. Мне лень и вообще памяти 4 гига.

Че ты ляпаешь?

Он ( alexferman) трольвкаждойбочкезатчыка, к тому же пустослов (другое слово). Не следует его сообщения читать.

Я игрался с рейдом на юсб-флешках. Из уже много, их не жалко, малые размеры не проблема.