Re: general thoughts and questions + general and RAID5/6 stability?

[Austin S Hemmelgarn <ahferroin7@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3100 bytes --]

On 2014-09-23 09:06, Stefan G. Weichinger wrote:
> 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?
Well, running 'mkfs.btrfs -O list-all' with 3.16 btrfs-progs gives the 
following list of features:
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.
>
> 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 ?
>
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.

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.



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]