[ale] Linux 5.0 File-System Benchmarks: Btrfs vs. EXT4 vs. F2FS vs. XFS

[Jim Kinney]

Huge partitions are a PITA! They are only a kludge workaround for "need a few hundred TB but don't know yet how the data will be organized".

sigh

I am frequently a "special" person :-)

On January 10, 2019 8:04:27 AM EST, DJ-Pfulio <DJPfulio at jdpfu.com> wrote:
>In the old days, we were taught to use RAID10 with at least 4 drive
>stripes to get 80% of the possible performance improvements.  If you
>needed more drives, get the DBA and storage teams to work out a way to
>get 16-way RAID10, though it will be a hassle for any future
>maintenance
>and doesn't provide nearly as much added performance as the initial
>4-way striping does.  Don't use RAID5 with databases or very large
>disks
>(2TB+).
>
>If you never need to reduce the file systems, only grow it, then XFS is
>the only choice besides ZFS.  Very few projects will ever outgrow EXT4
>size limits.  You are "special", Jim.  Whenever I've worked large
>storage projects, we partitioned the data for both speed and
>maintainability reasons.  Having 1 huge file system seems more
>convenient, but often it isn't long-term.  The added hassles of storage
>management at that scale (and chance of total deletion, cough) often
>outweigh the simplistic architecture that non-computer people want.
>
>
>BTRFS lies both to df and du. The only way to get accurate data is to
>use btrfs-specific tools. Many people don't mind that, but many people
>do.
>
></soapbox>
>
>
>On 1/10/19 7:47 AM, Jim Kinney wrote:
>> Inability to reduce xfs partition size is it's only problem. I've hit
>> size limit for ext4. The (newly realized for me) issue of df being
>> screwy with btrfs is a showstopper.
>> 
>> I've always mitigated performance issues with more spindles. Now it's
>> nvme for journals and cache.
>> 
>> At an oracle training (sales pitch), they showed specs on a specific
>> configuration with really good numbers. Basically indexes were stored
>on
>> raid1 nvme and data on spinning rust. Makes complicated joins
>screaming
>> fast. Postresql can do it too.
>> 
>> On January 9, 2019 8:56:30 PM EST, DJ-Pfulio via Ale <ale at ale.org>
>wrote:
>> 
>>     F2FS did well in that comparison. Surprising.
>>     Been using ext4 for almost everything for years.  Sometimes being
>able
>>     to reduce a file system is handy.
>> 
>>     When I learned that btrfs lied to df and du, I was out.
>> 
>>     On 1/9/19 8:41 PM, Raj Wurttemberg via Ale wrote:
>> 
>>         I saw that you all were talking about the BTRFS file system
>and
>>         remembered
>>         this article from a few days ago. I build and maintain large
>SAP
>>         HANA
>>         database servers (physical and virtual) so my only choice is
>the
>>         XFS file
>>         system which we have been quite happy with.
>> 
>>         Anyway... Interesting read.... :)
>> 
>>         Linux 5.0 File-System Benchmarks: Btrfs vs. EXT4 vs. F2FS vs.
>XFS
>> 
>>        
>https://www.phoronix.com/scan.php?page=article&item=linux-50-filesystems&num
>>         =1 

-- 
Sent from my Android device with K-9 Mail. All tyopes are thumb related and reflect authenticity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20190110/e1af434b/attachment.html>