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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html