On 3/28/24 14:42, Christoph Hellwig wrote: > On Thu, Mar 28, 2024 at 02:20:17PM +0900, Damien Le Moal wrote: >> I do not think that is corect. Because is_flush indicates that RQF_FLUSH_SEQ is >> set, that is, we are in the middle of a flush sequence. And flush sequence >> progression is handled at the request level, not BIOs. Once the sequence >> finishes, then and only then the BIO original endio should be done, meaning that >> we will then take this path and actually do blk_zone_update_request_bio() and >> bio_endio(). So I still think this is correct. > > Well. > > lk_flush_restore_request with the previous patch now restores rq->__sector, > and the blk_mq_end_request call following it will propagate it to the > original bio. But blk_flush_restore_request grabs the sector from > rq->bio->bi_iter.bi_sector, and we need to actually get it there first, > which is done by the data I/O completion that has RQF_FLUSH_SEQ set. Ah. Yes. There is no issue with the current code for regular writes, but we would get the original sector and not the written sector in the case of zone append. Will make the change. > I think we really need a good test case for zone append and FUA, > i.e. we need the append op for zonefs, which should exercise the > fua code if O_SYNC/O_DSYNC is set. Yep. There is currently no issuer of zone append + FUA. But once I get to add that for zonefs and block dev files, we indeed will have good tstbed. > -- Damien Le Moal Western Digital Research
