Tobias Geerinckx-Rice posted on Thu, 23 Oct 2014 16:47:19 +0200 as excerpted:
> On 22 October 2014 04:08, Duncan <1i5t5.dun...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html