Le 28/12/2017 à 20:49, Adam Borowski a écrit :
On Tue, Dec 26, 2017 at 05:20:58PM -0800, Rick Moen wrote:
btrfs is still scarily beta after rather a lot of years of development.
Its prospects have dimmed further now that Red Hat have dropped it from
their roadmap.
And why would Red Hat matter? It's similar to as if Apple dropped an iTunes
app for Android.
Red Hat never participated in btrfs development, has its own enterprisey
storage tools it peddles to paying customers that directly compete with
btrfs' features, never bothered to fix systemd's issues with basic btrfs
operation. Also, on their paid distribution (RHEL not Fedora), they provide
ridiculously ancient kernels they then backport features to. This is not
going to work for a filesystem of the complexity of btrfs unless you put
enough manpower on fixing issues caused by such backporting: Red Hat never
had as much as a single engineer dedicated to btrfs. No wonder they don't
want to get involved.
If, say, SuSE or Facebook backed out, _this_ would be a concern.
As for its state: btrfs is, well, btrfs. You get both extremely powerful
data protection features you won't want to live without, and WTF level
caveats. I wouldn't recommend using btrfs unless you know where the corpses
are buried.
But if you do, you get:
* data and metadata checksums. It is scary how inadequate disks' own
checksums are, and how often firmware bugs, bad cables, motherboard or
hostile fairies cause data corruption. On ext*, this leads to silent data
loss that you then discover months later once backups get overwritten.
Out of all my bad disks/eMMC/SD since I started looking at this, that were
not total device loss, at least some silent corruption happened in _every_
_single_ _case_. You have for example two sectors the controller reported
and 3K other sectors it did not.
* better chances to survive unclean shutdown than non-cow filesystem. Ext*
can be told to provide an equivalent level of protection but then it needs
to write every bit of data twice.
* O(changes) backup. Using rsync, a spinning disk is likely to take half an
hour just to stat() everything (obviously depends on the number of files).
Btrfs on the other hand can enumerate writes since a past snapshot, and
immediately knows what to transfer. If you wanted a full backup every 15
minutes, here you go.
* snapshots to protect from human error. You are a human, so are your
distro's developers. If X is broken again, you revert to the last working
snapshot with a single command. Awesome when running unstable.
These were data protection features. You also get compression,
deduplication, reflinks, etc.
There are performance downsides, but for POSIX operations, they're
restricted to fsync() and random writes. There are also performance
upsides: on a slow medium (SD/eMMC, 100Mbit ethernet NBD, etc) compression
can double performance for well-compressible workloads (such as package
building: sources, .o files and especially debug info compress nicely), and
even without compression, switching git branch is ~4 times faster on a SD
card on btrfs and f2fs compared to ext4.
Other downside is the need for maintenance. On single dev, you can live
well without, but on multi dev you need to do manually a lot that's taken
for granted with MD.
Another caveat: don't forget to mount with noatime.
So, many attractive features but a lot of learning and maintenance
work. Plus bugs. The more powerfull the software the more complex and
error prone. AFAIR, noatime doesn't imply nodiratime, therefore rather
specify both.
Didier
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
