[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    Enabling quota may not correctly rescan on 4.17
From:       Misono Tomohiro <misono.tomohiro () jp ! fujitsu ! com>
Date:       2018-06-26 6:00:24
Message-ID: 0ced0e29-9ecc-01fb-b0a5-9de32966666e () jp ! fujitsu ! com
[Download RAW message or body]

Hello Nikolay,

I noticed that commit 5d23515be669 ("btrfs: Move qgroup rescan
on quota enable to btrfs_quota_enable") in 4.17 sometimes causes
to fail correctly rescanning quota when quota is enabled.

Simple reproducer:

$ mkfs.btrfs -f $DEV
$ mount $DEV /mnt
$ dd if=/dev/urandom of=/mnt/file bs=1000 count=1000
$ btrfs quota enbale /mnt
$ umount /mnt
$ btrfs check $DEV
...
checking quota groups
Counts for qgroup id: 0/5 are different
our:            referenced 1019904 referenced compressed 1019904
disk:           referenced 16384 referenced compressed 16384
diff:           referenced 1003520 referenced compressed 1003520
our:            exclusive 1019904 exclusive compressed 1019904
disk:           exclusive 16384 exclusive compressed 16384
diff:           exclusive 1003520 exclusive compressed 1003520
found 1413120 bytes used, error(s) found
...

This can be also observed in btrfs/114. (Note that progs < 4.17
returns error code 0 even if quota is not consistency and therefore
test will incorrectly pass.)

My observation is that this commit changed to call initial quota rescan
when quota is enabeld instead of first comit transaction after enabling
quota, and therefore if there is something not commited at that time,
their usage will not be accounted.

Actually this can be simply fixed by calling "btrfs rescan" again or
calling "btrfs fi sync" before "btrfs quota enable".

I think the commit itself makes the code much easier to read, so it may
be better to fix the problem in progs (i.e. calling sync before quota enable).

Do you have any thoughts?

Thanks,
Tomohiro Misono


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]