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

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

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

On 2015-07-09 14:33, David Sterba wrote:
> On Thu, Jul 09, 2015 at 08:48:00AM -0400, Austin S Hemmelgarn 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".
>>>
>> No, there is a bit in the subvolume metadata that says whether it's
>> considered a snapshot or not.
>
> Technically it's not really a bit. The snapshot relation is determined
> by the parent uuid value of a subvolume.
I'm actually kind of curious, is the parent UUID actually used for 
anything outside of send/receive?
>
>> Internally, they are handled identically,
>> but it does come into play when you consider things like btrfs subvolume
>> show -s (which only lists snapshots),
>
> That was probably 'btrfs subvol list -s', though the 'subvol show'
> command prints all snapshots of a given subvolume.
You're right, I just have a tendency to get the two confused because my 
workflow means that I don't use either very frequently.
>
>> which in turn means that certain
>> tasks are more difficult to script robustly.
>
> I don't deny the interface/output is imperfect for scripting purposes,
> maybe we can provide filters that would satisfy your usecase.
>
Personally, I don't really do much direct scripting of BTRFS related 
tasks (although that might change if I can convince my boss that we 
should move to BTRFS for our server systems).  Most of my complaint with 
the current arrangement is primarily aesthetic more than anything else.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2967 bytes --]