btrfs as default filesystem for F22?

Ric Wheeler rwheeler at redhat.com
Tue Oct 7 01:28:07 UTC 2014


On 10/06/2014 10:30 AM, Eric Sandeen wrote:
> On 10/6/14 7:45 AM, Ralf Corsepius wrote:
>> On 10/06/2014 02:29 PM, Gene Czarcinski wrote:
>>
>>> Now, there is another question which has not been voiced: what is
>>> the "plan" for filessystems in Fedora (and by implication RHEL)?
>>> Is it BTRFS?  Or, perhaps is it LVM with XFS?  IIRC, some time ago
>>> it was stated that the plan was to move to BTRFS.  It is not clear
>>> to me that everyone is onboard with that decision.  Or, perhaps
>>> that decision is being reconsidered.
>> Let me answer from the position of a mere user. It's not clear to me
>> why and when users should switch to BTRFS or xfs or else, nor am I
>> not interested in using anything which would potentially endanger
>> existing installations (So far, reports I am reading from openSUSE
>> users don't necessarily sound convincing).
>>
>> In other words, you'd have to do a lot of marketing and convincing
>> work to persuade users to use BTRFS/xfs etc.
>>
>> Ralf
> I think this is an important point.  To make a fundamental change like
> this, the rationale and benefits need to be very clearly spelled out,
> and not just chase the new hotness (although 6-7 years in, I'm not sure
> btrfs can be called new?  XFS certainly can't!) ;)
>
> IOWs, I'd like to see much more than "because it can do snapshots and
> checksums" as the rationale; there are most definitely interesting things
> that btrfs can do (or is working on doing), but as btrfs has evolved, so has
> the rest of the Linux storage ecosystem: DM thin provisioning, xfs and ext4
> metadata checksums, System Storage Manager (SSM) aiming for administration
> ease, etc.
>
> It's up to those proposing a new default to clearly spell out the compelling
> advantage to the change.
>
> -Eric

I see btrfs as doing a few things that currently cannot be done with device 
mapper + xfs/ext4:

* full data and metadata data integrity checking
* fine grained control for compression/encryption
* ability to quickly reverse map from a block (and most interesting block level 
error) into something meaningful (file, metadata, etc)

Things that btrfs does well include the ease of use and built in support for 
snapshots, but I think that device mapper and other user space projects have 
worked hard to provide some of that for the traditional file systems.

Of course, all of these features need to be rock solid (and easy to repair) for 
production users.

Ric



More information about the devel mailing list