A f2fs partition on my Android phone has recently become corrupted. It will still mount fine; however, I completely lost access to one directory (/data/media/0), which now shows as empty. Yet the disk space hasn't changed at all.

When running fsck.f2fs from the terminal, it refuses to check on a mounted filesystem. I cannot unmount the data partition or remount it as read-only. Fine. After rebooting under recovery mode, where the partition is not mounted, I get this when running fsck.f2fs:

~ # fsck.f2fs /dev/block/mmcblk0p39
Info: sector size = 512
Info: total sectors = 21425920 (in 512bytes)

Assertion failed!
[fsck_chk_dentry_blk: 563] le32_to_cpu(de_blk->dentry[i].hash_code) == hash_code

So it still refuses to help me and it now fails with an obscure error… stating the directory gives me:

root@victara:/ # stat /data/media/0                                            
  File: `/data/media/0'
  Size: 4096     Blocks: 24  IO Blocks: 4096    directory
Device: 10307h/66311d    Inode: 4    Links: 35
Access: (770/drwxrwx---)    Uid: (1023/media_rw)    Gid: (1023/media_rw)
Access: 2016-04-04 16:55:56.800148001
Modify: 2016-04-05 02:47:44.314999998
Change: 2016-04-05 02:47:44.314999998

The inode (number?) seemed to be quite low… So I checked other directories:

root@victara:/ # stat /data/media/
  File: '/data/media/'
  Size: 4096        Blocks: 16         IO Block: 4096   directory
Device: 10307h/66311d   Inode: 4078        Links: 4    
Access: (0770/drwxrwx---)  Uid: ( 1023/media_rw)   Gid: ( 1023/media_rw)
__bionic_open_tzdata: couldn't find any tzdata when looking for localtime!
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
__bionic_open_tzdata: couldn't find any tzdata when looking for posixrules!
Access: 2016-04-04 14:48:25.000000000
Modify: 1970-01-01 02:27:21.000000000
Change: 1970-02-07 02:30:36.000000000

root@victara:/ # stat /data/media/obb                                          
  File: `/data/media/obb'
  Size: 4096     Blocks: 16  IO Blocks: 4096    directory
Device: 10307h/66311d    Inode: 4080     Links: 3
Access: (775/drwxrwxr-x)    Uid: (1023/media_rw)    Gid: (1023/media_rw)
Access: 1970-01-01 03:27:21.519999999
Modify: 2016-03-17 22:38:30.505748550
Change: 2016-04-04 17:42:31.569999988

It looks like the parent dir (/data/media) has inode 4078, another child of the parent (/data/media/obb) has inode 4080. So, logically, /data/media/0 should have inode 4079, but stat tells me it has inode 4.

So it looks like the filesystem metadata got corrupted. Without help from fsck.f2fs and debugfs (which sadly doesn't exist for f2fs), and in a pretty minimal Linux environment (Android recovery), is there a way I can correct the inode number or something else I can do to recover access to my data?

Interestingly, the directory still seems to be taking up disk space, and it is considered as "not empty" so I cannot remove it.

root@victara:/data/media # rm -rf 0
rm: 0: Directory not empty
1|root@victara:/data/media # ls
0 obb 
root@victara:/data/media # ls -al 0                                                                             
total 0

IMPORTANT: I cannot test solutions anymore since I need the phone and the storage space and reformatted the partition.

  • Can you mount this partition on a PC via e.g. USB? Do you have a badblocks utility or a system log (this may be a hardware fault)? – L. Levrel Apr 9 '16 at 8:07
  • the latest fsck.f2fs takes option -f to force repair a filesystem, and -a to auto repair. – meuh Apr 9 '16 at 10:46
  • I don't think there are bad blocks on it; I would have confirmed it, but there's no such utility in the recovery environment. f2fs really does not seem reliable… when compared to ext4. – Léo Lam Apr 9 '16 at 12:46
  • @meuh sadly, this is a failed assertion, so fsck.f2fs is refusing to even look at the file system because something it expects to be true is false. I can't even get it to check the FS, let alone repair it. – Léo Lam Apr 9 '16 at 12:48
  • 1
    Now it won't even boot into recovery mode (probably because it detects that /data is corrupted). I guess I need to reformat it… and use ext4. This is the second time f2fs has been so unreliable. – Léo Lam Apr 9 '16 at 21:45
Assertion failed!
[fsck_chk_dentry_blk: 563] le32_to_cpu(de_blk->dentry[i].hash_code) == hash_code

"Assertion failed" means an internal error in the program, in this case in fsck.f2fs. Basically it means that something the programmer expected to be always true, wasn't.

A production-grade program should always deal with errors with something better than "assertion failed" messages - at minimum, it should give a more descriptive error message. Sometimes an "assertion failed" error means you're hitting a rare corner case the developer is aware of, but hasn't implemented yet.

In this case, the only option is to see if there is a newer version of the program available, and hope that it's been updated to handle situations like this in some sensible fashion. If a newer version is only available in source code form from the upstream developer, and it fixes the problem, it might be necessary to send a bug report to the maintainer of your Linux distribution, indicating that the distribution should either package the updated version, or backport the relevant patch.

If the newest source code version from the upstream developer cannot handle this either, it's definitely time to send a bug report to the developer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.