On Mon, Sep 7, 2020 at 1:52 PM Damien Le Moal <[email protected]> wrote: > > On 2020/09/07 16:01, Kanchan Joshi wrote: > >> Even for SMR, the user is free to set the elevator to none, which disables > >> zone > >> write locking. Issuing writes correctly then becomes the responsibility of > >> the > >> application. This can be useful for settings that for instance use NCQ I/O > >> priorities, which give better results when "none" is used. > > > > Was it not a problem that even if the application is sending writes > > correctly, scheduler may not preserve the order. > > And even when none is being used, re-queue can happen which may lead > > to different ordering. > > "Issuing writes correctly" means doing small writes, one per zone at most. In > that case, it does not matter if the block layer reorders writes. Per zone, > they > will still be sequential. > > >> As far as I know, zoned drives are always used in tightly controlled > >> environments. Problems like "does not know what other applications would be > >> doing" are non-existent. Setting up the drive correctly for the use case > >> at hand > >> is a sysadmin/server setup problem, based on *the* application (singular) > >> requirements. > > > > Fine. > > But what about the null-block-zone which sets MQ-deadline but does not > > actually use write-lock to avoid race among multiple appends on a > > zone. > > Does that deserve a fix? > > In nullblk, commands are executed under a spinlock. So there is no concurrency > problem. The spinlock serializes the execution of all commands. null_blk zone > append emulation thus does not need to take the scheduler level zone write > lock > like scsi does.
I do not see spinlock for that. There is one "nullb->lock", but its scope is limited to memory-backed handling. For concurrent zone-appends on a zone, multiple threads may set the "same" write-pointer into incoming request(s). Are you referring to any other spinlock that can avoid "same wp being returned to multiple threads". -- Kanchan
