On 10/6/18 8:14 PM, Eric Sandeen wrote:
On 10/6/18 6:20 PM, Dave Chinner wrote:
Can you give an example of a use case that would be negatively affected
if this heuristic was switched from "sunit" to "sunit < swidth"?
Any time you only know a single alignment characteristic of the
underlying multi-disk storage. e.g. hardware RAID0/5/6 that sets
iomin = ioopt, multi-level RAID constructs where only the largest
alignment requirement is exposed, RAID1 devices exposing their chunk
size, remote replication chunk alignment (because remote rep. is
slow and so we need more concurrency to keep the pipeline full),
etc.
So the tl;dr here is "given any iomin > 512, we should infer low seek
latency and parallelism and adjust geometry accordingly?"
-Eric
Chiming in late here, but I do think that every decade or two (no disrespect to
xfs!), it is worth having a second look at how the storage has changed under us.
The workload that has lots of file systems pounding on a shared device for
example is one way to lay out container storage.
No argument about documenting how to fix this with command line tweaks for now,
but maybe this would be a good topic for the next LSF/MM shared track of file &
storage people to debate?
Ric
