On 7/20/23 01:31, Bart Van Assche wrote: > On 7/19/23 02:59, Damien Le Moal wrote: >> On 7/19/23 07:53, Bart Van Assche wrote: >>> I think what has been explained above is a scenario in which the filesystem >>> allocates requests per zone in another order than the LBA order. How about >>> requiring that the filesystem allocates and submits zoned writes in LBA >>> order >>> per zone? I think that this is how F2FS supports zoned storage. >> >> Sure. But what if an application uses the drive directly ? You loose >> guarantees of forward progress then. Given that an application has to >> use direct IO for writes to sequential zones, this is unlikely to happen >> in a "good" scenario, but it also would not be hard to write an >> application that can deadlock the drive forever by simply missing one >> write in a sequence of writes for a zone... That is my concern. While >> f2fs would likely be OK, the delay approach is not solid enough for all >> cases. > > Hi Damien, > > This patch series increases the number of retries for zoned writes > submitted by a filesystem. Direct I/O from user space is not affected > since the code that increases the number of retries occurs in > sd_setup_read_write_cmnd(). As you know scsi_prepare_cmd() only calls > sd_setup_read_write_cmnd() for requests that come from a filesystem > and not for pass-through requests. > > Does this address your concern? Not really. I was not thinking about passthrough requests but rather write syscalls to /dev/sdX by applications. sd_setup_read_write_cmnd() is used for these too. After all, /dev/sdX *is* a file system too, albeit the simplest possible. > > Thanks, > > Bart. > -- Damien Le Moal Western Digital Research
