On 09/24/2014 10:53 AM, Helmut Tessarek wrote: > On 2014-09-24 0:09, Stan Hoeppner wrote: >> If you create any striped arrays, especially parity arrays, with md make >> sure to manually specify chunk size and match it to your workload. The >> current default is 512KB. This is too large for a great many workloads, >> specifically those that are metadata heavy or manipulate many small >> files. 512KB wastes space and with parity arrays causes RMW, hammering >> throughput and increasing latency. > > Thanks again for the valueable information. > > I used to work with databases on storage subsystems, so placing GBs of > database containers for tableapaces on arrays with a larger stripe size > was actually beneficial. > For log files and other data I usually used different cache settings and > strip sizes. > > So how does this work with SW RAID? > > Does the XFS chunk size equal the amount of data touched by a single r/w > operation? No. The XFS stripe unit size (chunk size) must/should equal the underlying RAID stripe unit size (chunk). As Eric said, all this does is help XFS align allocations to the underlying RAID geometry in an attempt to get more full chunk/stripe writes on the disks. Note we both said allocation. The XFS sunit/swidth settings have no affect with file appends or writing into preallocated files. > I'm asking because data is usually written in page/extent sizes for > databases. Even if I have a container with 50GB, I might only have to > read/write a 4k page. db operations are going to be append or modify-in-place. Neither will benefit from aligning XFS to the RAID geometry. Appending the db logs is also not allocation. So in practical terms, you simply would not use the "-d" striping options during mkfs.xfs. Use the defaults. Cheers, Stan _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
