Re: btrfs subvolume clone or fork (btrfs-progs feature request)

[Roman Mamedov <rm@romanrm.net>]

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

On Thu, 09 Jul 2015 08:48:00 -0400
Austin S Hemmelgarn <ahferroin7@gmail.com> wrote:

> On 2015-07-09 08:41, Sander wrote:
> > Austin S Hemmelgarn wrote (ao):
> >>> What's wrong with "btrfs subvolume snapshot"?
> >>
> >> Well, personally I would say the fact that once something is tagged as
> >> a snapshot, you can't change it to a regular subvolume without doing a
> >> non-incremental send/receive.
> >
> > A snapshot is a subvolume. There is no such thing as "tagged as a
> > snapshot".
> >
> > 	Sander
> >
> No, there is a bit in the subvolume metadata that says whether it's 
> considered a snapshot or not.  Internally, they are handled identically, 
> but it does come into play when you consider things like btrfs subvolume 
> show -s (which only lists snapshots), which in turn means that certain 
> tasks are more difficult to script robustly.

This sounds like a vestigial leftover from back when snapshots were
conceptualized to be somehow functionally different from subvolumes... But as
you said, now there is effectively no difference, so that bit is used for
what, only to track how a subvolume was created? And to output in the
subvolume list if the user passes "-s"? I'd say that's a pretty oddball feature
to even have, since in any case if you want to distinguish and list only your
snapshots, you would typically just name them in a certain way, e.g.
"/snaps/originalname/<datetime>".

-- 
With respect,
Roman

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