On 11/3/18 5:20 PM, Nikolay Borisov wrote:


On 3.11.18 г. 3:34 ч., Su Yue wrote:


On 2018/11/2 10:10 PM, Christoph Anton Mitterer wrote:
Hey Su.


Sorry for the late reply cause I'm busy at other things.

Anything further I need to do in this matter or can I consider it
"solved" and you won't need further testing by my side, but just PR the
patches of that branch? :-)


I just looked through related codes and found the bug.
The patches can fix it. So no need to do more tests.
Thanks to your tests and patience. :)


In previous output of debug version, we can see @ret code
is 524296 which is (DIR_ITEM_MISMATCH(1 << 3) | DIR_INDEX_MISMATCH
(1<<19)).

In btrfs-progs v4.17,
function check_inode_extref() passes u64 @mode as the last parameter
of find_dir_item();
However, find_dir_item() is defined as:
static int find_dir_item(struct btrfs_root *root, struct btrfs_key *key,
                          struct btrfs_key *location_key, char *name,
                          u32 namelen, u8 file_type);

The type of the last argument is u8 not u64.

So this would have been caught by gcc's -Wconversion, except it likely
wouldn't have been because right now this option produces loads of false
positives... Too bad...
Yes, type cast is too common in C, enabling such compile warnings
is annoying...



So the case is that while checking files with inode_extrefs,
if (imode != file_type), then find_dir_item() thinks it found
DIR_ITEM_MISMATCH or DIR_INDEX_MISMATCH.

Thanks,
Su

Thanks,
Chris.

On Sat, 2018-10-27 at 14:15 +0200, Christoph Anton Mitterer wrote:
Hey.


Without the last patches on 4.17:

checking extents
checking free space cache
checking fs roots
ERROR: errors found in fs roots
Checking filesystem on /dev/mapper/system
UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c
found 619543498752 bytes used, error(s) found
total csum bytes: 602382204
total tree bytes: 2534309888
total fs tree bytes: 1652097024
total extent tree bytes: 160432128
btree space waste bytes: 459291608
file data blocks allocated: 7334036647936
   referenced 730839187456


With the last patches, on 4.17:

checking extents
checking free space cache
checking fs roots
checking only csum items (without verifying data)
checking root refs
Checking filesystem on /dev/mapper/system
UUID: 6050ca10-e778-4d08-80e7-6d27b9c89b3c
found 619543498752 bytes used, no error found
total csum bytes: 602382204
total tree bytes: 2534309888
total fs tree bytes: 1652097024
total extent tree bytes: 160432128
btree space waste bytes: 459291608
file data blocks allocated: 7334036647936
   referenced 730839187456


Cheers,
Chris.






Reply via email to