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 afilesystem 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.
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.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 :-)
smime.p7s
Description: S/MIME Cryptographic Signature
