On Friday, August 27, 2021 at 10:10:15 AM Phillip Susi wrote: > >This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email. > > >Damien Le Moal <damien.lemoal@xxxxxxx> writes: > >> Single LUN multi-actuator hard-disks are cappable to seek and execute >> multiple commands in parallel. This capability is exposed to the host >> using the Concurrent Positioning Ranges VPD page (SCSI) and Log (ATA). >> Each positioning range describes the contiguous set of LBAs that an >> actuator serves. > >Are these ranges exlusive to each actuator or can they overlap? > >> This series does not attempt in any way to optimize accesses to >> multi-actuator devices (e.g. block IO schedulers or filesystems). This >> initial support only exposes the independent access ranges information >> to user space through sysfs. > >Is the plan to eventually change the IO scheduler to maintain two >different queues, one for each actuator, and send down commands for two >different IO streams that the elevator attempts to keep sequential? > > There is nothing in the spec that requires the ranges to be contiguous or non-overlapping. It's easy to imagine a HDD architecture that allows multiple heads to access the same sectors on the disk. It's also easy to imagine a workload scenario where parallel access to the same disk could be useful. (Think of a typical storage design that sequentially writes new user data gradually filling the disk, while simultaneously supporting random user reads over the written data.) The IO Scheduler is a useful place to implement per-actuator load management, but with the LBA-to-actuator mapping available to user space (via sysfs) it could also be done at the user level. Or pretty much anywhere else where we have knowledge and control of the various streams. The system is flexible and adaptable to a really wide range of HDD designs and usage models. Best regards, -Tim Tim Walker Seagate Research
