On Fri, Aug 14, 2020 at 1:44 PM hch@xxxxxxxxxxxxx <hch@xxxxxxxxxxxxx> wrote: > > On Wed, Aug 05, 2020 at 07:35:28AM +0000, Damien Le Moal wrote: > > > the write pointer. The only interesting addition is that we also want > > > to report where we wrote. So I'd rather have RWF_REPORT_OFFSET or so. > > > > That works for me. But that rules out having the same interface for raw block > > devices since O_APPEND has no meaning in that case. So for raw block devices, it > > will have to be through zonefs. That works for me, and I think it was your idea > > all along. Can you confirm please ? > > Yes. I don't think think raw syscall level access to the zone append > primitive makes sense. Either use zonefs for a file-like API, or > use the NVMe pass through interface for 100% raw access. But there are use-cases which benefit from supporting zone-append on raw block-dev path. Certain user-space log-structured/cow FS/DB will use the device that way. Aerospike is one example. Pass-through is synchronous, and we lose the ability to use io-uring. For async uring/aio to block-dev, file-pointer will not be moved to EoF, but that position was not very important anyway- as with this interface we expect many async appends outstanding, all with zone-start. Do you think RWF_APPEND | RWF_REPORT_OFFSET_DIRECT/INDIRECT is too bad for direct block-dev. Could you please suggest another way to go about it? -- Kanchan
