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
