On Wed, Dec 13, 2023 at 08:41:32AM -0800, Jaegeuk Kim wrote: > I don't have any > concern to keep the same ioprio on writes, since handheld devices are mostly > sensitive to reads. So, if you have other use-cases using zoned writes which > require different ioprio on writes, I think you can suggest a knob to control > it by users. Get out of your little handheld world. In Linux we need a generally usable I/O stack, and any feature exposed by the kernel and will be used quite differently than you imagine. Just like people will add reordering to the I/O stack that's not there right now (in addition to the ones your testing doesn't hit). That doensn't mean we should avoid them - you genereally get better performance by not reordering without a good reason (like thotting), but especially in error handling paths or resource constrained environment they will hapen all over. We've had this whole discussion with the I/O barriers that did not work for exactly the same reasons. > > > > > > it is essential to place the data per file to get better bandwidth. And for > > > NAND-based storage, filesystem is the right place to deal with the more efficient > > > garbage collecion based on the known data locations. > > > > And that works perfectly fine match for zone append. > > How that works, if the device gives random LBAs back to the adjacent data in > a file? And, how to make the LBAs into the sequential ones back? Why would your device pick random LBAs? If you send a zone append to zone it will be written at the write pointer, which is absolutely not random. All I/O written in a single write is going to be sequential, so just like for all other devices doing large sequential writes is important. Multiple writes can get reordered, but if you havily hit the same zone you'd get the same effect in the file system allocator too. > Sorry, I needed to stop reading here, as you're totally biased. This is not > the case in JEDEC, as Bart spent multiple years to synchronize the technical > benefitcs that we've seen across UFS vendors as well as OEMs. *lol* There is no more fucked up corporate pressure standard committee than the storage standards in JEDEC. That's why not one actually takes them seriously.
