[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-aio
Subject:    Re: [PATCH v4 6/6] io_uring: add support for zone-append
From:       Luis Chamberlain <mcgrof () kernel ! org>
Date:       2022-03-02 20:51:51
Message-ID: 20220302205151.76f6wfqb2t3llnvf () garbanzo
[Download RAW message or body]

On Fri, Jul 31, 2020 at 07:45:26AM +0100, hch@infradead.org wrote:
> On Fri, Jul 31, 2020 at 06:42:10AM +0000, Damien Le Moal wrote:
> > > - We may not be able to use RWF_APPEND, and need exposing a new
> > > type/flag (RWF_INDIRECT_OFFSET etc.) user-space. Not sure if this
> > > sounds outrageous, but is it OK to have uring-only flag which can be
> > > combined with RWF_APPEND?
> > 
> > Why ? Where is the problem ? O_APPEND/RWF_APPEND is currently meaningless for
> > raw block device accesses. We could certainly define a meaning for these in the
> > context of zoned block devices.
> 
> We can't just add a meaning for O_APPEND on block devices now,

Make sense.

Is a new call system call for nameless writes called for instead then?
Then there is no baggage. Or is this completely stupid?

> as it was previously silently ignored.  I also really don't think any
> of these semantics even fit the block device to start with.  If you
> want to work on raw zones use zonefs, that's what is exists for.

Using zonefs adds a slight VFS overhead. Fine if we want to live with
that, but I have a feeling if we want to do something like just testing
hot paths alone to compare apples to apples we'd want something more
fine grained.

  Luis

--
To unsubscribe, send a message with 'unsubscribe linux-aio' in
the body to majordomo@kvack.org.  For more info on Linux AIO,
see: http://www.kvack.org/aio/
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>
[prev in list] [next in list] [prev in thread] [next in thread]