Subject: Re: [CentOS] Btrfs going forward, was: Errors on
an SSD drive
On Aug 11, 2017, at 12:39 PM, hw <[email protected]
> Warren Young wrote:
>>>> What do they suggest as a replacement?
>> Stratis: https://stratis-storage.github.io/StratisSoftwareDesign.pdf
> Can I use that now?
As I said, they’re targeting the first testable releases for Fedora 28.
Whether, how, and on what schedule Stratis gets into RHEL will be based on how
well those tests go.
So, if you want Stratis in RHEL or CentOS and you want it to be awesome, you
need to get involved with Fedora. Wishes are not changes.
> How do you install on an XFS that is adjusted to the stripe size and the
> number of
> units when using hardware RAID?
That’s one of many reasons why you want to use software RAID if at all
possible. Software RAID makes many things easier than with hardware RAID.
Hardware RAID made the most sense when motherboards came with only 2 PATA ports
and CPUs were single-core and calculated parity at double-digit percentages of
the CPU’s capacity. Over time, the advantages of hardware RAID have been
> What if you want to use SSDs to install the system on? That usually puts
> RAID of the question.
SSD and other caching layers are explicitly part of the Stratis design, but
won’t be in its first versions.
Go read the white paper.
> I don´t want the performance penalty MD brings about even as a home user.
You keep saying that. 
> Same goes for ZFS.
You want data checksumming and 3+ copies of metadata and copy-on-write and… but
it all has to come for free?
> I can´t tell yet how the penalty looks with btrfs,
> only that I haven´t noticed any yet.
> And that brings back the question why nobody makes a hardware ZFS controller.
They do. It’s called an Intel Xeon. :)
All RAID is software, at some level.
> Enterprise users would probably love that, provided that the performance
> could be resolved.
Enterprise users *do* have hardware ZFS appliances:
These are FreeBSD and Illumos-based ZFS storage appliances, respectively, with
all the enterprisey features you could want, and they’re priced accordingly.
> Just try to copy a LV into another VG, especially when the VG resides on
> different devices.
ZFS send/receive makes that pretty easy. You can even do it incrementally by
coupling it with snapshots. It’s fast enough that people use this to set up
> Or try to make a snapshot in another VG
> because the devices the source of the snapshot resides on don´t have enough
I don’t think any volume managing filesystem will fix that problem. Not enough
space is not enough space.
I think the best answer to that provided by ZFS is, “Why do you have more than
one pool?” Not a great answer, but it should at least make you re-justify
your current storage design to yourself.
CentOS mailing list