Re: [PATCH v2 3/5] btrfs-progs: kernel based default features for mkfs

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

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

On 2015-11-23 11:14, Christoph Anton Mitterer wrote:
> On Mon, 2015-11-23 at 11:05 -0500, Austin S Hemmelgarn wrote:
>> I would find it useful if btrfs gives a warning if it creates a
>>> filesystem which (because unsupported in the current kernel) lacks
>>> features which are considered default by then.
>> It should give a warning if the user requests a feature that is
>> unsupported by the kernel it's being run on, but it should not by
>> default try to enable something that isn't supported by the kernel
>> it's
>> running on.
> Well that as well, and of course it shouldn't try to enable a feature
> that wouldn't work, but what I meant was, e.g. if I create a fs with
> btrfs-progs 4.3 (where skinny-extents are default) but on such an old
> kernel where this isn't supported yet,... it should tell me "Normally
> I'd create the fs with skinny-extents, but I don't as your kernel is
> too old".
Ah, I misunderstood your meaning, that would be nice to have.
>> It is actually possible to clone a btrfs filesystem, just not in a
>> way
>> that people used to stuff like ext4 would recognize.  In essence, you
>> need to take the FS mostly off-line, force all subvolumes to read-
>> only,
>> then use send-receive to transfer things, and finally make the
>> subvolumes writable again.  I've been considering doing a script to
>> do
>> this automatically, but have never gotten around to it as it's not
>> something that is quick to code, and it's not something I do very
>> often.
> And that would also keep all ref-links, etc.? I.e. the copied fs
> wouldn't eat up much more space than the original?
> Well than such script should be part of btrfs-progs :-)
There's no way to reliably preserve _all_ ref-links, but between 
snapshots and the subvolumes they are snapshots of, it should, assuming 
that you either send them all at once (which would take a long time 
probably), or that you do proper incremental transfers.  The other 
disadvantage is that it may not (depending on the features of course) 
cause any new features to be used except on new files.



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