RFC: mkfs.btrfs --subvols UI [was Re: [PATCH] btrfs-progs: add --subvol option to mkfs.btrfs]

[Nicholas D Steeves <sten@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

Hello,

Qu Wenruo <quwenruo.btrfs@gmx.com> writes:

> 在 2024/6/27 19:24, Mark Harmstone 写道:
>> From: Mark Harmstone <maharmstone@meta.com>
>>
>> This patch adds a --subvol option, which tells mkfs.btrfs to create the
>> specified directories as subvolumes.
>
> I have considered this feature in the past, but I do not have a good
> enough UI for that.

Recursive subvol backup & restore seems to be a desired feature, so I've
considered that in the following:

Goffredo Baroncelli <kreijack@libero.it> writes:

> On 27/06/2024 11.54, Mark Harmstone wrote:
>
> Could be possible to decouple the "--rootdir" and the "--subvol" options ?
> I.e. doing a first iteration where only the subvolume/subdir are created and a second one where
> all the subvolume are populated.
>

This also makes the most sense to me.  In terms of UI, what are the
downsides to the following:

mkfs.btrfs --subvols 1 2 3 4 5 $device
# Creates a flat layout

mkfs.btrfs --subvols subdir/1 subdir/2 subdir/3 subdir/subsubdir/4 \
  subdir/subsubdir/5 $device
# Creates subvols inside plain directories

unless this is specified:

mkdir.btrfs --subvols sv_cont0 sv_cont1 \
 --subvols sv_cont0/1 sv_cont0/2 sv_cont1/3 sv_cont1/4 \
   sv_cont2/5

This creates nested subvolumes, and "sv_cont2/5" will create subvol=5 in
a plain-dir named "sv_cont2" (the gotcha!/pitfall).  Each subsequent
"--subvols foo bar baz" argument creates deeper level of nested
subvolumes.  If the necessary parents haven't yet been created as
subvolumes, they are always created as directories.

And then "--rootdir" unpacks (yes, I'm conceptualising of rootdir as a
tarball).  That said, I wonder if rootdir.img is a special
high-performance format, and wonder if it could benefit from a TOC to
collate subvolumes.  This also seems orthogonal to a future btrfs send
image type would recurse and store subvol layout in a TOC of some kind.

Regards,
Nicholas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]