| Message ID | 1377901546-22434-1-git-send-email-dsterba@suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Thank you for addressing this, David. On Sat, Aug 31, 2013 at 1:25 AM, David Sterba <dsterba@suse.cz> wrote: > 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". > " > > There is a performance penalty incured by the change, but deleting a > subvolume is not a frequent operation and the tradeoff seems justified > by getting the guarantee stated above. > > CC: Alex Lyakas <alex.btrfs@zadarastorage.com> > CC: Josef Bacik <jbacik@fusionio.com> > Signed-off-by: David Sterba <dsterba@suse.cz> > --- > fs/btrfs/ioctl.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c > index e407f75..4394632 100644 > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -2268,7 +2268,7 @@ static noinline int btrfs_ioctl_snap_destroy(struct file *file, > out_end_trans: > trans->block_rsv = NULL; > trans->bytes_reserved = 0; > - ret = btrfs_end_transaction(trans, root); > + ret = btrfs_commit_transaction(trans, root); > if (ret && !err) > err = ret; > inode->i_flags |= S_DEAD; > -- > 1.7.9 > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sun, Oct 20, 2013 at 08:19:59AM -0400, Chris Mason wrote: > My objections are pretty similar to Josef's. But, there's no reason we > can't change the progs to optionally trigger a commit. Works for me, though I'm not clear what should be the default. > What I want to avoid is bulk snapshot deletion triggering a commit for > each individual snapshot. I agree and came to the same conclusion later on. david -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c index e407f75..4394632 100644 --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -2268,7 +2268,7 @@ static noinline int btrfs_ioctl_snap_destroy(struct file *file, out_end_trans: trans->block_rsv = NULL; trans->bytes_reserved = 0; - ret = btrfs_end_transaction(trans, root); + ret = btrfs_commit_transaction(trans, root); if (ret && !err) err = ret; inode->i_flags |= S_DEAD;
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". " There is a performance penalty incured by the change, but deleting a subvolume is not a frequent operation and the tradeoff seems justified by getting the guarantee stated above. CC: Alex Lyakas <alex.btrfs@zadarastorage.com> CC: Josef Bacik <jbacik@fusionio.com> Signed-off-by: David Sterba <dsterba@suse.cz> --- fs/btrfs/ioctl.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)