On Tue, 05 Jun 2012 15:36:29 -0500 Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx> wrote: > > Except this would not make any sense even as a thought experiment. You don't > > want a configuration where two or more areas of the same physical disk need to > > be accessed in parallel for any read or write to the volume. And it's pretty > > easy to avoid that. > > You make a good point but your backing argument is incorrect: XFS by > design, by default, writes to 4 equal sized regions of a disk in parallel. I said: "...need to be accessed in parallel for any read or write". With XFS you mean allocation groups, however I don't think that if you write any large file sequentially to XFS, it will always cause drive's head to jump around between four areas because the file is written "in parallel", striped to four different locations, which is the main problem that we're trying to avoid. XFS allocation groups are each a bit like an independent filesystem, to allow for some CPU- and RAM-access-level parallelization. However spinning devices and even SSDs can't really read or write quickly enough "in parallel", so parallel access to different areas of the same device is used in XFS not for *any read or write*, but only in those cases where that can be beneficial for performance -- and even then, likely managed carefully either by XFS or by lower level of I/O schedulers to minimize head movements. -- With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free."
Attachment:
signature.asc
Description: PGP signature
