On 2/10/2012 10:33 PM, Ori Bani wrote: > On Thu, Feb 9, 2012 at 3:51 PM, Stan Hoeppner <s...@hardwarefreak.com> wrote: >> On 2/8/2012 8:24 PM, Bill Cole wrote: >> >>> I would stay away from btrfs until it is much more mature. As a general >>> rule (very general) mail systems stress allocation and metadata >>> efficiency more than sustained data flow, so you'd want to avoid options >>> like the older versions of XFS. >> >> "older versions of XFS" in this context would be kernel versions 2.6.35 >> and earlier. 2.6.36 introduced the delayed logging patch which makes >> XFS metadata performance equal to and greater than EXT4, depending on >> concurrency level. At 8 threads or more XFS with delaylog has the best >> metadata performance of any Linux FS. > > Thanks for the info! Do you use XFS for all/part of your mail > system(s)?
Of course. But in my case I use it for reasons other than mail throughput as my mail stream isn't all that big. > Any other helpful hints or anecdotes? XFS performance is primarily built around parallelism. Any application workload or mix thereof that generates lots of concurrent reads/writes will benefit from XFS. As will any application that deals with extremely large files or filesystems, terabytes to petabytes and many millions of directories and files. I.e. "large and lots". And after all the updates over the past couple of years it's just as good as EXT4 on single threaded workloads. You didn't mention your storage hardware, which has a direct bearing on filesystem performance. I assume you're using a non-parity array of some sort, either fiber channel, iSCSI, or direct attach SAS/SATA with at least 4 or more spindles of throughput (8 disk RAID10) for user mail files, and at least a mirrored pair of disks for the Postfix spool directories, if not all on the same array. If you're doing something like using single disk drives, with a filesystem on each, or worse yet, multiple partitions and filesystems on a single drive, then it won't matter much which filesystem you use. Using parity RAID will drag performance down as well, throttling your filesystem performance. Any workload with a high random write IO pattern will suck dramatically with parity RAID. Using the same controller and number of drives, RAID10 will typically have 3-5+ times the random write performance of RAID5/6 due to the latter's RMW operations on the stripes. The same holds true when using XFS atop a concatenated set of mirror pairs--due to XFS allocation group parallelism, this latter array type is usually even slightly faster than a RAID10 array with mail workloads. Last but not least, if you don't have BBWC/FBWC, write performance will suck no matter what you do elsewhere, unless you leave the drive caches enabled. But if you do that you have serious reliability issues, for not only file data, but for the file system journal as well. One power drop, hardware crash, or kernel panic, and you have a corrupted filesystem due to data in drive caches not having hit the platter. Fsync and barriers can sometimes help here, but a lot of drives ack fsync when data hits the cache chip, not the platter, so you can't trust the drive caches. So make sure you have a good array controller with BBWC/FBWC, and a good UPS. Once those things are in place, then build everything else properly atop this hardware. -- Stan
