Re: [PATCH] btrfs: commit transaction after deleting a subvolume

[Chris Mason <chris.mason@fusionio.com>]

Quoting David Sterba (2013-08-30 18:25:46)
> Alex pointed out the consequences after a transaction is not committed
> when a subvolume is deleted, so in case of a crash before an actual
> commit happens will let the subvolume reappear.
> 
> Original post:
> http://www.spinics.net/lists/linux-btrfs/msg22088.html
> 
> Josef's objections:
> http://www.spinics.net/lists/linux-btrfs/msg22256.html
> 
> While there's no need to do a full commit for regular files, a subvolume
> may get a different treatment.
> 
> http://www.spinics.net/lists/linux-btrfs/msg23087.html:
> 
> "That a subvol/snapshot may appear after crash if transation commit did
> not happen does not feel so good. We know that the subvol is only
> scheduled for deletion and needs to be processed by cleaner.
> 
> From that point I'd rather see the commit to happen to avoid any
> unexpected surprises.  A subvolume that re-appears still holds the data
> references and consumes space although the user does not assume that.
> 
> Automated snapshotting and deleting needs some guarantees about the
> behaviour and what to do after a crash. So now it has to process the
> backlog of previously deleted snapshots and verify that they're not
> there, compared to "deleted -> will never appear, can forget about it".
> "

My objections are pretty similar to Josef's.  But, there's no reason we
can't change the progs to optionally trigger a commit.

What I want to avoid is bulk snapshot deletion triggering a commit for
each individual snapshot.  

-chris