Linux-BTRFS Archive on lore.kernel.org
 help / Atom feed
From: Robert White <rwhite@pobox.com>
To: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Feature Request: Directory property to upconvert mkdir/rmdir to subvol create/delete
Date: Sat, 18 May 2019 04:06:40 +0000
Message-ID: <a108b077-ff18-7c6d-ac5c-ea666de48084@pobox.com> (raw)

Howdy,

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.

             reply index

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-18  4:06 Robert White [this message]
2019-05-20 11:26 ` David Sterba

Reply instructions:

You may reply publically 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=a108b077-ff18-7c6d-ac5c-ea666de48084@pobox.com \
    --to=rwhite@pobox.com \
    --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

Linux-BTRFS Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-btrfs/0 linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ https://lore.kernel.org/linux-btrfs \
		linux-btrfs@vger.kernel.org linux-btrfs@archiver.kernel.org
	public-inbox-index linux-btrfs


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs


AGPL code for this site: git clone https://public-inbox.org/ public-inbox