Re: Poll: time to switch skinny-metadata on by default?

[Duncan <1i5t5.duncan@cox.net>]

Tobias Geerinckx-Rice posted on Thu, 23 Oct 2014 16:47:19 +0200 as
excerpted:

> On 22 October 2014 04:08, Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Since the kernel has code for both "fat" metadata and skinny-metadata,
>> they can exist side-by-side and the kernel will use whichever code is
>> appropriate.
> 
> I understand that the fat extent code will probably never be removed for
> compatibility reasons, but do wonder why it's still the default.
> Caution?

Caution, backward kernel compatibility, and simply timing.

The skinny code is newer, and there were several skinny-metadata related 
bugs in the first couple kernel cycles it was available, so not making it 
the immediate default was certainly wise.  Tho the new code has been 
reasonably stable for awhile, now.  But that's exactly why this 
discussion, is it time to make the new code the default yet, or not, 
because it hasn't been done yet.

Additionally, some people want to keep the flexibility to mount with old 
kernels.  Consider a distro installation and rescue image (ISO or USB), 
for instance.  Those can be used for rescue purposes for not only the 
life of that distro release, but for sometime afterward.  If the only 
rescue image you can find is a two year old image and it won't mount your 
btrfs because the on-device format has changed since then and your 
filesystem is the newer format, you're going to be one frustrated btrfs 
user!

> Petr Janecek's balancing problem [1] and similar bugs aside: is there a
> functional reason to prefer "fat" over skinny metadata for future file
> systems?

Other than keeping backward compatibility to work with old rescue images 
and the like, as discussed above, not that I'm aware of.  IOW, I know of 
no corner-case where fat metadata is now more efficient or more stable.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman