On 12/20/23 12:53, Christoph Hellwig wrote: > On Wed, Dec 20, 2023 at 10:28:37AM +0900, Damien Le Moal wrote: >> zone, and as I said before, since doing that is nonsensical, getting the IOs to >> fail is fine by me. The user will then be aware that this should not be done. >> >> f2fs has a problem with that though as that leads to write errors and FS going >> read-only (I guess). btrfs will not have this issue because it uses zone append. >> Need to check dm-zoned as their may be an issue there. >> >> So what about what I proposed in an earlier email: introduce a bio flag "ignore >> ioprio" that causes bio_set_ioprio() to not set any IO priority and have f2fs >> set that flag for any zone write BIO it issues ? That will solve your f2fs issue >> without messing up good use cases. > > How can this even be a problem for f2f2 upsteam where f2fs must only > have a single write per zone outstanding? I really don't want crap > in the block layer to work around a known broken model (multiple > outstanding WRITE commands per zone) that because it's so known broken > isn't even merged upstream. The only constraint at the BIO level for writing to a zone is "issue the write BIOs sequentially". So multiple write BIOs *can* be issued to a zone. The "one write per zone in flight at any time" implemented with zone write locking happens at the request level in the block IO scheduler, so underneath the file system. So the issue can indeed happen. But what you said could actually provide a solution: have the FS issue regular writes one at a time if the writes have priorities. -- Damien Le Moal Western Digital Research
