On 2014-09-23 09:06, Stefan G. Weichinger wrote:
Well, running 'mkfs.btrfs -O list-all' with 3.16 btrfs-progs gives the following list of features:Am 23.09.2014 um 14:08 schrieb Austin S Hemmelgarn:On 2014-09-22 16:51, Stefan G. Weichinger wrote:Is re-creating btrfs-filesystems *recommended* in any way?Does that actually make a difference in the fs-structure?I would recommend it, there are some newer features that you can only set at mkfs time. Quite often, when a new feature is implemented, it is some time before things are such that it can be enabled online, and even then that doesn't convert anything until it is rewritten.What features for example?
mixed-bg - mixed data and metadata block groups extref - increased hard-link limit per file to 65536 raid56 - raid56 extended format skinny-metadata - reduced size metadata extent refs no-holes - no explicit hole extents for files mixed-bg is something that you generally wouldn't want to change after mkfs.extref can be enabled online, and the filesystem metadata gets updated as-needed, and dosen't provide any real performance improvement (but is needed for some mail servers that have HUGE mail-queues) I don't know anything about the raid56 option, but there isn't any way to change it after mkfs. skinyy-metadata can be changed online, and the format gets updated on rewrite of each metadata block. This one does provide a performance improvement (stat() in particular runs noticeably faster). You should probably enable this if it isn't already enabled, even if you don't recreate your filesystem. no-holes cannot currently be changed online, and is a very recent addition (post v3.14 btrfs-progs I believe) that provides improved performance for sparse files (which is particularly useful if you are doing things with fixed size virtual machine disk images).
It's this last one that prompted me personally to recreate my filesystems most recently, as I use sparse files to save space as much as possible.
AFAIK there isn't really any 'version number' that has any meaning in the superblock (except for telling the kernel that it uses the stable disk layout), however, there are flag bits that you can look for (compat_flags, compat_ro_flags, and incompat_flags). I'm not 100% certain what each bit means, but on my system with a only 1 month old BTRFS filesystem, with extref, skinny-metadata, and no-holes turned on, i have compat_flags: 0x0, compat_ro_flags: 0x0, and incompat_flags: 0x16b.I created my main btrfs a few months ago and would like to avoid recreating it as this would mean restoring my root-fs on my main workstation. Although I would do it if it is "worth it" ;-) I assume I could read some kind of version number out of the superblock or so? btrfs-show-super ?
The other potentially significant thing is that the default nodesize/leafsize has changed recently from 4096 to 16384, as that gives somewhat better performance for most use cases.
smime.p7s
Description: S/MIME Cryptographic Signature
