Неправильный inode: повреждённый f2fs, fsck.f2fs не может восстановить.

Недавно раздел f2fs на моем Android телефоне стал поврежден. Он продолжает монтироваться нормально; однако я полностью потерял доступ к одной директории (/data/media/0), которая теперь отображается как пустая. Тем не менее, дискоспейс не изменился вообще.

При выполнении fsck.f2fs из терминала он отказывается проверять смонтированную файловую систему. Я не могу размонтировать раздел данных или перемонтировать его в режиме только для чтения. Хорошо. После перезагрузки в режиме восстановления, где раздел не смонтирован, я получаю это при выполнении fsck.f2fs:

~ # fsck.f2fs /dev/block/mmcblk0p39
Info: размер сектора = 512
Info: всего секторов = 21425920 (в 512 байт)

Неудача утверждения!
[fsck_chk_dentry_blk: 563] le32_to_cpu(de_blk->dentry[i].hash_code) == hash_code

Таким образом, он все еще отказывается мне помочь и теперь выдает неясную ошибку… Выполнение stat на директории дает мне:

root@victara:/ # stat /data/media/0                                            
  Файл: `/data/media/0'
  Размер: 4096     Блоки: 24  IO Блоки: 4096    директория
Устройство: 10307h/66311d    Идентификатор: 4    Ссылки: 35
Доступ: (770/drwxrwx---)    UID: (1023/media_rw)    GID: (1023/media_rw)
Доступ: 2016-04-04 16:55:56.800148001
Изменение: 2016-04-05 02:47:44.314999998
Изменение: 2016-04-05 02:47:44.314999998

Идентификатор (номер?) казался довольно низким… Поэтому я проверил другие директории:

root@victara:/ # stat /data/media/
  Файл: '/data/media/'
  Размер: 4096        Блоки: 16         IO Блок: 4096   директория
Устройство: 10307h/66311d   Идентификатор: 4078        Ссылки: 4    
Доступ: (0770/drwxrwx---)  UID: ( 1023/media_rw)   GID: ( 1023/media_rw)
__bionic_open_tzdata: не удалось найти ни одну tzdata при поиске localtime!
__bionic_open_tzdata: не удалось найти ни одну tzdata при поиске GMT!
__bionic_open_tzdata: не удалось найти ни одну tzdata при поиске posixrules!
Доступ: 2016-04-04 14:48:25.000000000
Изменение: 1970-01-01 02:27:21.000000000
Изменение: 1970-02-07 02:30:36.000000000

root@victara:/ # stat /data/media/obb                                          
  Файл: `/data/media/obb'
  Размер: 4096     Блоки: 16  IO Блоки: 4096    директория
Устройство: 10307h/66311d    Идентификатор: 4080     Ссылки: 3
Доступ: (775/drwxrwxr-x)    UID: (1023/media_rw)    GID: (1023/media_rw)
Доступ: 1970-01-01 03:27:21.519999999
Изменение: 2016-03-17 22:38:30.505748550
Изменение: 2016-04-04 17:42:31.569999988

Похоже, что родительская директория (/data/media) имеет идентификатор 4078, а другой дочерний элемент родителя (/data/media/obb) имеет идентификатор 4080. Следовательно, логически /data/media/0 должен иметь идентификатор 4079, но stat говорит мне, что он имеет идентификатор 4.

Похоже, что метаданные файловой системы были повреждены. Без помощи от fsck.f2fs и debugfs (которого, к сожалению, не существует для f2fs), и в довольно минимальной среде Linux (восстановление Android), есть ли способ, которым я могу исправить номер инод или что-то еще, что я могу сделать, чтобы восстановить доступ к своим данным?

Интересно, что директория по-прежнему, похоже, занимает дисковое пространство и считается “непустой”, поэтому я не могу ее удалить.

root@victara:/data/media # rm -rf 0
rm: 0: Директория не пустая
1|root@victara:/data/media # ls
0 obb 
root@victara:/data/media # ls -al 0                                                                             
всего 0

ВАЖНО: Я больше не могу тестировать решения, так как мне нужен телефон и место для хранения, и я переформатировал раздел.

Неудача утверждения!
[fsck_chk_dentry_blk: 563] le32_to_cpu(de_blk->dentry[i].hash_code) == hash_code

“Неудача утверждения” означает внутреннюю ошибку в программе, в данном случае в fsck.f2fs. По сути, это означает, что что-то, что программист ожидал быть всегда истинным, не было таковым.

Программа для производственных систем должна всегда обрабатывать ошибки с чем-то лучше, чем сообщения “неудача утверждения” – как минимум, она должна дать более подробное сообщение об ошибке. Иногда ошибка “неудача утверждения” означает, что вы наткнулись на редкий крайний случай, о котором разработчик знает, но еще не реализовал.

В данном случае единственный вариант – посмотреть, есть ли новая версия программы, и надеяться, что она была обновлена для обработки таких ситуаций каким-то разумным образом. Если новая версия доступна только в виде исходного кода от upstream разработчика и исправляет проблему, возможно, потребуется отправить отчет об ошибке поддерживающему вашу Linux дистрибутив, указывая, что дистрибутив должен либо упаковать обновленную версию, либо применить соответствующий патч.

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