On 2017年12月02日 09:23, Tomasz Pala wrote: > On Sat, Dec 02, 2017 at 08:27:56 +0800, Qu Wenruo wrote: > >> I assume there is program eating up the space. >> Not btrfs itself. > > Very doubtful. I've encountered ext3 "eating" problem once, that couldn't be > find by lsof on 3.4.75 kernel, but the space was returning after killing > Xorg. The system I'm having problem now is very recent, the space > doesn't return after reboot/emergency and doesn't sum up with files.
Unlike vanilla df or "fi usage" or "fi df", btrfs quota only counts on-disk extents. That's to say, reserved space won't contribute to qgroup. Unless one is using anonymous file, which is opened but unlinked, so no one can access it except the owner. (Which I doubt that may be your case) Which should make quota the best tool to debug your problem. (As long as you follow the variant limitations of btrfs quota, especially you need to sync or use --sync option to show qgroup numbers) > >>> Now, the weird part for me is exclusive data count: >>> >>> # btrfs sub sh ./snapshot-171125 >>> [...] >>> Subvolume ID: 388 >>> # btrfs fi du -s ./snapshot-171125 >>> Total Exclusive Set shared Filename >>> 21.50GiB 63.35MiB 20.77GiB snapshot-171125 >> >> That's the difference between how sub show and quota works. >> >> For quota, it's per-root owner check. > > Just to be clear: I've enabled quota _only_ to see subvolume usage on > spot. And exclusive data - the more detailed approach I've described in > e-mail I've send a minute ago. > >> Means even a file extent is shared between different inodes, if all >> inodes are inside the same subvolume, it's counted as exclusive. >> And if any of the file extent belongs to other subvolume, then it's >> counted as shared. > > Good to know, but this is almost UID0-only system. There are system > users (vendor provided) and 2 ssh accounts for su, but nobody uses this > machine for daily work. The quota values were the last tool I could find > to debug. > >> For fi du, it's per-inode owner check. (The exact behavior is a little >> more complex, I'll skip such corner case to make it a little easier to >> understand). >> >> That's to say, if one file extent is shared by different inodes, then >> it's counted as shared, no matter if these inodes belong to different or >> the same subvolume. >> >> That's to say, "fi du" has a looser condition for "shared" calculation, >> and that should explain why you have 20+G shared. > > There shouldn't be many multi-inode extents inside single subvolume, as this > is mostly fresh > system, with no containers, no deduplication, snapshots are taken from > the same running system before or after some more important change is > done. By 'change' I mean altering text config files mostly (plus > etckeeper's git metadata), so the volume of difference is extremelly > low. Actually most of the difs between subvolumes come from updating > distro packages. There were not much reflink copies made on this > partition, only one kernel source compiled (.ccache files removed > today). So this partition is as clean, as it could be after almost > 5 months in use. > > Actually I should rephrase the problem: > > "snapshot has taken 8 GB of space despite nothing has altered source > subvolume" Then please provide correct qgroup numbers. The correct number should be get by: # btrfs quota enable <mnt> # btrfs quota rescan -w <mnt> # btrfs qgroup show -prce --sync <mnt> Rescan and --sync are important to get the correct number. (while rescan can take a long long time to finish) And further more, please ensure that all deleted files are really deleted. Btrfs delay file and subvolume deletion, so you may need to sync several times or use "btrfs subv sync" to ensure deleted files are deleted. (vanilla du won't tell you if such delayed file deletion is really done) Thanks, Qu >
signature.asc
Description: OpenPGP digital signature
