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? > > 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". david -- 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
