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. 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. 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. 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). -- Tomasz Pala <go...@pld-linux.org> -- 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
