All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Thumshirn <Johannes.Thumshirn@wdc.com>
To: Christoph Hellwig <hch@lst.de>
Cc: "hch@infradead.org" <hch@infradead.org>,
	Damien Le Moal <Damien.LeMoal@wdc.com>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Jens Axboe <axboe@kernel.dk>,
	"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>
Subject: Re: [PATCH 2/2] zonefs: use zone-append for AIO as well
Date: Wed, 22 Jul 2020 15:00:49 +0000	[thread overview]
Message-ID: <SN4PR0401MB35989A410533DAF58739D53B9B790@SN4PR0401MB3598.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20200722145156.GA20266@lst.de

On 22/07/2020 16:52, Christoph Hellwig wrote:
> On Wed, Jul 22, 2020 at 12:43:21PM +0000, Johannes Thumshirn wrote:
>> On 21/07/2020 07:54, Christoph Hellwig wrote:
>>> On Mon, Jul 20, 2020 at 04:48:50PM +0000, Johannes Thumshirn wrote:
>>>> On 20/07/2020 15:45, Christoph Hellwig wrote:
>>>>> On Mon, Jul 20, 2020 at 10:21:18PM +0900, Johannes Thumshirn wrote:
>>>>>> On a successful completion, the position the data is written to is
>>>>>> returned via AIO's res2 field to the calling application.
>>>>>
>>>>> That is a major, and except for this changelog, undocumented ABI
>>>>> change.  We had the whole discussion about reporting append results
>>>>> in a few threads and the issues with that in io_uring.  So let's
>>>>> have that discussion there and don't mix it up with how zonefs
>>>>> writes data.  Without that a lot of the boilerplate code should
>>>>> also go away.
>>>>>
>>>>
>>>> OK maybe I didn't remember correctly, but wasn't this all around 
>>>> io_uring and how we'd report the location back for raw block device
>>>> access?
>>>
>>> Report the write offset.  The author seems to be hell bent on making
>>> it block device specific, but that is a horrible idea as it is just
>>> as useful for normal file systems (or zonefs).
>>
>> After having looked into io_uring I don't this there is anything that
>> prevents io_uring from picking up the write offset from ki_complete's
>> res2 argument. As of now io_uring ignores the filed but that can be 
>> changed.
> 
> Sure.  Except for the fact that the io_uring CQE doesn't have space
> for it.  See the currently ongoing discussion on that..

That one I was aware of, but I thought once that discussion has settled
the write offset can be copied from res2 into what ever people have agreed
on by then.

> 
>> So the only thing that needs to be done from a zonefs perspective is 
>> documenting the use of res2 and CC linux-aio and linux-abi (including
>> an update of the io_getevents man page).
>>
>> Or am I completely off track now?
> 
> Yes.  We should not have a different ABI just for zonefs.  We need to
> support this feature in a generic way and not as a weird one off for
> one filesystem and only with the legacy AIO interface.

OK, will have a look.

> Either way please make sure you properly separate the interface (
> using Write vs Zone Append in zonefs) from the interface (returning
> the actually written offset from appending writes), as they are quite
> separate issues.

So doing async RWF_APPEND writes using Zone Append isn't the problem here,
it's "only" the reporting of the write offset back to user-space? So once
we have sorted this out we can start issuing zone appends for zonefs async
writes?

Thanks,
	Johannes


  reply	other threads:[~2020-07-22 15:00 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-20 13:21 [PATCH 0/2] zonefs: use zone-append for aio with rwf append Johannes Thumshirn
2020-07-20 13:21 ` [PATCH 1/2] fs: fix kiocb ki_complete interface Johannes Thumshirn
2020-07-20 13:38   ` Christoph Hellwig
2020-07-20 13:43     ` Damien Le Moal
2020-07-20 13:47       ` Christoph Hellwig
2020-07-20 13:21 ` [PATCH 2/2] zonefs: use zone-append for AIO as well Johannes Thumshirn
2020-07-20 13:45   ` Christoph Hellwig
2020-07-20 16:48     ` Johannes Thumshirn
2020-07-21  5:54       ` Christoph Hellwig
2020-07-22 12:43         ` Johannes Thumshirn
2020-07-22 13:02           ` Damien Le Moal
2020-07-22 14:53             ` Christoph Hellwig
2020-07-22 14:51           ` Christoph Hellwig
2020-07-22 15:00             ` Johannes Thumshirn [this message]
2020-07-24 13:57             ` Kanchan Joshi
2020-07-27  3:12               ` Damien Le Moal
2020-07-21 12:43   ` Kanchan Joshi
2020-07-22 14:32     ` Johannes Thumshirn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SN4PR0401MB35989A410533DAF58739D53B9B790@SN4PR0401MB3598.namprd04.prod.outlook.com \
    --to=johannes.thumshirn@wdc.com \
    --cc=Damien.LeMoal@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=hch@infradead.org \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.