| Message ID | 1448283378-10579-4-git-send-email-anand.jain@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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.
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.
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.
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[] = {
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(-)