Is btrfs ready to be default fs in F17 ?
jb.1234abcd at gmail.com
Sun Nov 6 12:53:55 UTC 2011
Alan Cox <alan <at> lxorguk.ukuu.org.uk> writes:
> > But what about those atractive features (some ZFS-like) the users would
> > like to
> > have, e.g.:
> > - checksumming
> > - roll back
> > - snapshots
> > - pools
> > Is it possible to implement them on ext4 ?
> Possibly but the entire point of ext4 was to grow ext3 and do so in a
> maximally safe fashion. Some of the above you can do via LVM of course.
> > Perhaps writing off ext4 in favor of btrfs in context of new features
> > development is premature ?
> Doing btrfs development makes sense, but inflicting it by default on users
> who really have no need for it isn't quite the same discussion. For
> performance it's not showing any signs of being better than ext3/4 - in
> fact on some media its massively underperforming them currently. The
> funky feature set really isn't relevant to most users while their data
> still being available most definitely *is*.
Having btrfs developed by Oracle, with RH participation, in light of measures
and counter-measures with regard to RHEL and its "unlawful support" by Oracle,
is not a good recipe for common goals in btrfs dev.
Me thinks evolution, forking ext5 from ext4, and moving with it by original
ext4 devs irrespectively of some Linux player's interests, by progressively
adding the most attractive features mentioned above, seems like the most
optimal path. The current performance of ext4 vice btrfs justifies such a move.
Everybody would eventually benefit, but nobody with conflicting interests would
control the process.
More information about the users