linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Robert White <rwhite@pobox.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Feature Request: Directory property to upconvert mkdir/rmdir to subvol create/delete
Date: Mon, 20 May 2019 13:26:12 +0200	[thread overview]
Message-ID: <20190520112612.GD3138@twin.jikos.cz> (raw)
In-Reply-To: <a108b077-ff18-7c6d-ac5c-ea666de48084@pobox.com>

Hi,

On Sat, May 18, 2019 at 04:06:40AM +0000, Robert White wrote:
> For several reasons it would be really convenient if there was a way to 
> mark a btrfs directory such that the directories created in the marked 
> directory would actually be automatically converted to subvolume 
> creation and destruction.
> 
> NFS4 particularly pivots on file system boundaries, which it seems to 
> include subvolumes-in-place as such boundaries.
> 
> doing this to /home is another opportunity if you have transient 
> accounts created by scripts/programs you cannot easily change.
> 
> Other uses include creating virtual machine sets via tarballs and such.
> 
> It would also be super useful in apps that create large cache 
> directories that you'll eventually drop in bulk. /usr/src is another 
> place where large directories come and go under installer control.
> 
> The core logic would be to upconvert any legal rmdir to a subvol delete 
> if it's applied to a subvol. Yes, this _would_ remove non-empty subvols, 
> that would be the point. Then any mkdir in that directory would create a 
> subvol instead of a directory.
> 
> Normal files in the directory would be unchanged.
> 
> And a normal directory moved into the directory would remain a normal 
> directory for obvious reasons.
> 
> And a subvol moved out of the directory (can you even do that?) would 
> remain a subvol for equally obvious reasons.
> 
> It's implicit that the non-superuser create/remove subvol operation 
> would be legal for such a directory.
> 
> Programs could be rewritten to do this explicitly, of course, but that's 
> a heck of a lot of impractical patching.
> 
> Anyway, just a thought I've had repeatedly that I finally thought to broach.

My first reaction to the subject line subvolume/directory conversion
idea was not positive, the two objects have a different representation
inside the filesystem and I thought it was the idea that was on wiki.

But you bring something completely different and it's well thought
through, the usecase, some of the practical questions rmdir/mv. And I
think this is not actually hard to implement with current state of
attributes and bits available.

The file attributes/flags defined by ext2 and adopted by other
filesystems were originally specific to ext2, but nothing prevents us to
repurpose some of them. Lesser known flag 'T' (described in chattr(1))
marks a directory as 'top level of a hierarchy', and is an optimization
for block placement.

How can btrfs reuse the flag? In a directory with 'T', all mkdir will be
mksubvol, and rmdir on a subvolume would work as you describe.

The rename operation only updates the directory entry and does not
change the type of the object, ie. moving a directory to a 'T' directory
will not magically convert it to a subvolume.

The nice thing is that the 'T' bit is there, the semantics is IMHO close
to the original meaning and the tools to manage it are available.

So yes, this can be implemented, I'll put it on the wiki projects page.

      reply	other threads:[~2019-05-20 11:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-18  4:06 Feature Request: Directory property to upconvert mkdir/rmdir to subvol create/delete Robert White
2019-05-20 11:26 ` David Sterba [this message]

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=20190520112612.GD3138@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rwhite@pobox.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).