[v2,3/5] btrfs-progs: kernel based default features for mkfs
diff mbox

Message ID 1448283378-10579-4-git-send-email-anand.jain@oracle.com
State New
Headers show

Commit Message

Anand Jain Nov. 23, 2015, 12:56 p.m. UTC
Mkfs from latest btrfs-progs will enable latest default features,
and if the kernel is down-rev and does not support a latest default
feature then mount fails, as expected.

This patch disables default features based on the running kernel.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
v2: Check if sysfs tells what features are supported

 mkfs.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

Comments

Christoph Anton Mitterer Nov. 23, 2015, 3:57 p.m. UTC | #1
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.


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.


Cheers,
Chris.
Austin S. Hemmelgarn Nov. 23, 2015, 4:05 p.m. UTC | #2
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.
Christoph Anton Mitterer Nov. 23, 2015, 4:14 p.m. UTC | #3
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".


> 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 :-)

Cheers,
Chris.
Austin S. Hemmelgarn Nov. 23, 2015, 4:55 p.m. UTC | #4
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.

Patch
diff mbox

diff --git a/mkfs.c b/mkfs.c
index a5802f7..4f46ad9 100644
--- a/mkfs.c
+++ b/mkfs.c
@@ -1357,10 +1357,24 @@  int main(int ac, char **av)
 	int dev_cnt = 0;
 	int saved_optind;
 	char fs_uuid[BTRFS_UUID_UNPARSED_SIZE] = { 0 };
-	u64 features = BTRFS_MKFS_DEFAULT_FEATURES;
+	u64 features;
 	struct mkfs_allocation allocation = { 0 };
 	struct btrfs_mkfs_config mkfs_cfg;
 
+	/*
+	 * If kernel could tell supported features by sysfs then use it,
+	 * if not, then set it by static kernel version, if the this also
+	 * fails then default to the progs default, which is set as per
+	 * BTRFS_MKFS_DEFAULT_FEATURES
+	 */
+	if (btrfs_features_allowed_by_sysfs(&features))
+		features = btrfs_features_allowed_by_kernel();
+
+	if (features)
+		features &= BTRFS_MKFS_DEFAULT_FEATURES;
+	else
+		features = BTRFS_MKFS_DEFAULT_FEATURES;
+
 	while(1) {
 		int c;
 		static const struct option long_options[] = {