Hi David, On Thu, Mar 7, 2013 at 1:55 PM, David Sterba <dste...@suse.cz> wrote: > On Wed, Mar 06, 2013 at 10:12:11PM -0500, Chris Mason wrote: >> > > Also, I want to ask, hope this is not inappropriate. Do you also agree >> > > with Josef, that it's ok for BTRFS_IOC_SNAP_DESTROY not to commit the >> > > transaction, but just to detach from it? Had we committed, we would >> > > have ensured that ORPHAN_ITEM is in the root tree, thus preventing >> > > from subvol to re-appear after crash. >> > > It seems a little inconsistent with snap creation, where not only the >> > > transaction is committed, but delalloc flush is performed to ensure >> > > that all data is on disk before creating the snap. >> > >> > That's another question, can you please point me to the thread where >> > this was discussed? http://www.spinics.net/lists/linux-btrfs/msg22256.html
>> >> That's a really old one. The original snapshot code expected people to >> run sync first, but that's not very user friendly. The idea is that if >> you write a file and then take a snapshot, that file should be in the >> snapshot. > > The snapshot behaviour sounds ok to me. > > 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". Exactly. Currently, the user space has no idea when the deletion will start, or when it is completed (it has to track the ROOT_ITEM, drop progress, ORPHAN_ITEM etc.). That's why I was thinking, that at least committing a transaction on snap_destroy could ensure that deletion will not be reverted. Thanks, Alex. -- 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
