From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: [RFC] Improve subvolume usability for a normal user
Date: Thu, 7 Dec 2017 02:56:21 +0000 (UTC) [thread overview]
Message-ID: <pan$33b4a$60a76f26$86fed72c$a3e3152c@cox.net> (raw)
In-Reply-To: e1a297d8-28fb-980e-fd62-c261186b3a6a@gmail.com
Austin S. Hemmelgarn posted on Wed, 06 Dec 2017 07:39:56 -0500 as
excerpted:
> Somewhat OT, but the only operation that's remotely 'instant' is
> creating an empty subvolume. Snapshot creation has to walk the tree in
> the subvolume being snapshotted, which can take a long time (and as a
> result of it's implementation, also means BTRFS snapshots are _not_
> atomic). Subvolume deletion has to do a bunch of cleanup work in the
> background (though it may be fairly quick if it was a snapshot and the
> source subvolume hasn't changed much).
Indeed, while btrfs in general has taken a strategy of making /creating/
snapshots and subvolumes fast, snapshot deletion in particular can take
some time[1].
And in that regard a question just occurred to me regarding this whole
very tough problem of a user being able to create but not delete
subvolumes and snapshots:
Given that at least snapshot deletion (not so sure about non-snapshot
subvolume deletion, tho I strongly suspect it would depend on the number
of cross-subvolume reflinks) is already a task that can take some time,
why /not/ just bite the bullet and make the behavior much more like the
directory deletion, given that subvolumes already behave much like
directories. Yes, for non-root, that /does/ mean tracing the entire
subtree and checking permissions, and yes, that's going to take time and
lower performance somewhat, but subvolume and in particular snapshot
deletion is already an operation that takes time, so this wouldn't be
unduly changing the situation, and it would eliminate the entire class of
security issues that come with either asymmetrically restricting deletion
(but not creation) to root on the one hand, or possible data loss due to
allowing a user to delete a subvolume they couldn't delete were it an
ordinary directory due to not owning stuff further down the tree.
---
[1] Based on comments and reports here. My own use-case doesn't involve
snapshots/subvolumes.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2017-12-07 2:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-05 8:25 [RFC] Improve subvolume usability for a normal user Misono, Tomohiro
2017-12-05 8:43 ` Qu Wenruo
2017-12-05 12:41 ` Austin S. Hemmelgarn
2017-12-05 15:42 ` Graham Cobb
2017-12-05 18:01 ` Goffredo Baroncelli
2017-12-05 18:46 ` Graham Cobb
2017-12-05 19:09 ` Goffredo Baroncelli
2017-12-05 20:17 ` Austin S. Hemmelgarn
2017-12-05 22:08 ` Goffredo Baroncelli
2017-12-06 12:25 ` Austin S. Hemmelgarn
2017-12-06 4:52 ` Misono, Tomohiro
2017-12-06 12:39 ` Austin S. Hemmelgarn
2017-12-07 2:56 ` Duncan [this message]
2017-12-07 7:15 ` Misono, Tomohiro
2017-12-07 11:55 ` Duncan
2017-12-07 12:21 ` Austin S. Hemmelgarn
2017-12-07 13:45 ` Hugo Mills
2017-12-07 5:27 ` Qu Wenruo
2017-12-07 7:32 ` Marat Khalili
2017-12-07 7:59 ` Qu Wenruo
2017-12-05 18:24 ` Goffredo Baroncelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$33b4a$60a76f26$86fed72c$a3e3152c@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.