On 2018-01-13 08:56:24 [+0800], Qu Wenruo wrote: > 'Btrfs check' output please.
~# btrfs check --repair -p /dev/sdb4 enabling repair mode Checking filesystem on /dev/sdb4 UUID: b3bfb56e-d445-4335-93f0-c1fb2d1f6df1 Fixed 0 roots. checking extents [o] No device size related problem found cache and super generation don't match, space cache will be invalidated checkingunresolved ref dir 57648595 index 435 namelen 40 name 2f3f379b2a3d7499471edb74869efe-1948311.d filetype 1 errors 80, filetype mismatch unresolved ref dir 57648595 index 1137 namelen 39 name 454bf066ddfbf42e0f3b77ea71c82f-878732.o filetype 1 errors 100, name too long checking csums checking root refs found 63691468800 bytes used, no error found total csum bytes: 61339388 total tree bytes: 860536832 total fs tree bytes: 688816128 total extent tree bytes: 84545536 btree space waste bytes: 224424238 file data blocks allocated: 62890745856 referenced 62829219840 ~# > And in fact, btrfs check --repair has the ability to move/re-link such > file and keeps its content, as long as there is any info found in > DIR_INDEX/DIR_ITEM/INODE_REF. > > If repair can't handle it, the output could help us to craft such case > and enhance btrfs-progs to repair it. Is the output enough or do you want me to do more? > Thanks, > Qu Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html