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.
smime.p7s
Description: S/MIME cryptographic signature
