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: 1688 bytes --]

On 2015-11-23 10:57, Christoph Anton Mitterer wrote:
> Hey.
>
> On Mon, 2015-11-23 at 20:56 +0800, Anand Jain wrote:
>> This patch disables default features based on the running kernel.
> Not sure if that's very realistic in practise (most people will have
> some distro, whose btrfsprogs version probably matches the kernel), but
> purely from the end-user PoV:
>
> 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.
>
>
> AFAIU, really "clonding" (I mean including all snapshots, subvols,
> etc.) a btrfs is not possible right now (or is it?), so a btrfs is
> something that rather should stay longer (as one cannot easily
> copy&swap it to/with a new one)... so for me as an end-user, it may be
> easier to switch to a newer kernel, in order to get a feature which is
> default, than to migrate the fs later.
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.



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