On 6/29/20 8:39 AM, Josef Bacik wrote:
On 6/29/20 5:33 AM, Florian Weimer wrote:
> * Josef Bacik:
>> That being said I can make btrfs look really stupid on some workloads.
>> There's going to be cases where Btrfs isn't awesome. We still use xfs
>> for all our storage related tiers (think databases). Performance is
>> always going to be workload dependent, and Btrfs has built in overhead
>> out the gate because of checksumming and the fact that we generate far
>> more metadata.
> Just to be clear here, the choice of XFS here is purely based on
> performance, not on the reliability of the file systems, right?
> (So it's not “all the really important data is stored in XFS”.)
Yes that's correct. At our scale everything falls over, including XFS, and as
I've stated elsewhere in this thread we actually see a higher rate of failure
(relative to the install size) with XFS. The databases we use already do all of the fancy
things that btrfs does in the application. If we could get away with it we'd just use
raw disks for those applications. and in fact may do that in the future. Thanks,
Josef, with my XFS hat on, are these recent failures? Have they
all been reported to the XFS list?
It makes sense to look at reliability in the context of this thread, but
offering "btrfs fails less often than XFS for us" without any context
(what kind of failure, what kernel, when, etc) doesn't help much, it's
just more anecdotes.