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