Re: btrfs fi df output is not updated in a timely manner after subvolumes have been deleted

[Russell Coker <russell@coker.com.au>]

On Tue, 20 May 2014 14:50:10 Astro Xe wrote:
> On my box, the "used" value in the output of "btrfs filesystem df" is not
> updated in a timely manner, after that one or more subvolumes have been
> deleted. I need to execute "btrfs filesystem sync", in order to update the
> value.
> 
> How do I fix this? Or, could someone fix this in btrfs-progs, please?
> 
> I suspect the cause is that subvolumes are marked immediately as deleted,
> but cleaned up at a later time, is this right?

That appears to be the case.  I've deleted subvolumes and then had btrfs take 
10+ minutes to reclaim all the disk space.  I've even had the system crash 
during the process (due to btrfs bugs that seem fixed in 3.14) and the space 
keeps getting freed after the reboot.

Do we really want to make it the default to block on a btrfs sync?  In the 
case of manual sysadmin tasks it's probably going to be preferable to run the 
delete command and then move on to other things.

In the case of cron jobs we have to consider bulk performance, maybe it would 
be better for the authors of cron jobs to run a filesystem sync after deleting 
all snapshots to avoid driving the load average too high (I have had issues in 
the past when cron jobs to remove snapshots end up running at the same time as 
creating snapshots and scrubbing the filesystem).  If a cron job was to delete 
dozens of snapshots and sync after each one would that cause more disk access 
than syncing once after all deletes?

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/