On 2017年12月02日 09:43, Tomasz Pala wrote: > On Sat, Dec 02, 2017 at 09:05:50 +0800, Qu Wenruo wrote: > >>> qgroupid rfer excl >>> -------- ---- ---- >>> 0/260 12.25GiB 3.22GiB from 170712 - first snapshot >>> 0/312 17.54GiB 4.56GiB from 170811 >>> 0/366 25.59GiB 2.44GiB from 171028 >>> 0/370 23.27GiB 59.46MiB from 111118 - prev snapshot >>> 0/388 21.69GiB 7.16GiB from 171125 - last snapshot >>> 0/291 24.29GiB 9.77GiB default subvolume >> >> You may need to manually sync the filesystem (trigger a transaction >> commitment) to update qgroup accounting. > > The data I've pasted were just calculated. > >>> # btrfs quota enable / >>> # btrfs qgroup show / >>> WARNING: quota disabled, qgroup data may be out of date >>> [...] >>> # btrfs quota enable / - for the second time! >>> # btrfs qgroup show / >>> WARNING: qgroup data inconsistent, rescan recommended >> >> Please wait the rescan, or any number is not correct. > > Here I was pointing that first "quota enable" resulted in "quota > disabled" warning until I've enabled it once again. > >> It's highly recommended to read btrfs-quota(8) and btrfs-qgroup(8) to >> ensure you understand all the limitation. > > I probably won't understand them all, but this is not an issue of my > concern as I don't use it. There is simply no other way I am aware that > could show me per-subvolume stats. Well, straightforward way, as the > hard way I'm using (btrfs send) confirms the problem.
Unfortunately, send doesn't count everything. The most common thing is, send doesn't count extent booking space. Try the following command: # fallocate -l 1G <tmp_file> # mkfs.btrfs -f <tmp_file> # mount <tmp_file> <mnt> # btrfs subv create <mnt>/subv1 # xfs_io -f -c "pwrite 0 128M" -c "sync" <mnt>/subv1/file1 # xfs_io -f "fpunch 0 127M" -c "sync" <mnt>/subv1/file1 # btrfs subv snapshot -r <mnt>/subv1 <mnt>/snapshot # btrfs send <mnt>/snapshot You will only get the 1M data, while it still takes 128M space on-disk. Btrfs extent book will only free the whole extent if and only if there is no inode referring *ANY* part of the extent. Even only 1M of a 128M file extent is used, it will still takes 128M space on-disk. And that's what send can't tell you. And that's also what qgroup can tell you. That's also why I need *CORRECT* qgroup numbers to further investigate the problem. > > You could simply remove all the quota results I've posted and there will > be the underlaying problem, that the 25 GB of data I got occupies 52 GB. If you only want to know the answer why your "25G" data occupies 52G on disk, above is one of the possible explanations. (And I think I should put it into btrfs(5), although I highly doubt if user will really read them) You could try to defrag, but I'm not sure if defrag works well in multi subvolumes case. > At least one recent snapshot, that was taken after some minor (<100 MB) > changes > from the subvolume, that has undergo some minor changes since then, > occupied 8 GB during one night when the entire system was idling. The only possible method to fully isolate all the disturbing factors is to get rid of snapshot. Build the subvolume from scratch (even no cp --reflink from other subvolume), then test what's happening. Only in that case, you could trust vanilla du (if you don't do any reflink). Although you can always trust qgroups number, such subvolume built from scratch will makes exclusive number equals to reference, making debugging a little easier. Thanks, Qu > > This was crosschecked on files metadata (mtimes compared) and 'du' > results. > > > As a last-resort I've rebalanced the disk (once again), this time with > -dconvert=raid1 (to get rid of the single residue). >
signature.asc
Description: OpenPGP digital signature
