On Tue, Sep 29, 2020 at 6:54 AM Damien Le Moal wrote:
>
> On 2020/09/29 3:58, Kanchan Joshi wrote:
> [...]
> > ZoneFS is better when it is about dealing at single-zone granularity,
> > and direct-block seems better when it is about grouping zones (in
> > various ways including striping). The
On 2020/09/29 3:58, Kanchan Joshi wrote:
[...]
> ZoneFS is better when it is about dealing at single-zone granularity,
> and direct-block seems better when it is about grouping zones (in
> various ways including striping). The latter case (i.e. grouping
> zones) requires more involved mapping, and
On Fri, Sep 25, 2020 at 8:22 AM Damien Le Moal wrote:
>
> On 2020/09/25 2:20, Kanchan Joshi wrote:
> > On Tue, Sep 8, 2020 at 8:48 PM h...@infradead.org
> > wrote:
> >>
> >> On Mon, Sep 07, 2020 at 12:31:42PM +0530, Kanchan Joshi wrote:
> >>> But there are use-cases which benefit from
On 2020/09/25 2:20, Kanchan Joshi wrote:
> On Tue, Sep 8, 2020 at 8:48 PM h...@infradead.org wrote:
>>
>> On Mon, Sep 07, 2020 at 12:31:42PM +0530, Kanchan Joshi wrote:
>>> But there are use-cases which benefit from supporting zone-append on
>>> raw block-dev path.
>>> Certain user-space
On Tue, Sep 8, 2020 at 8:48 PM h...@infradead.org wrote:
>
> On Mon, Sep 07, 2020 at 12:31:42PM +0530, Kanchan Joshi wrote:
> > 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
> >
On Mon, Sep 07, 2020 at 12:31:42PM +0530, Kanchan Joshi wrote:
> 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
On Fri, Aug 14, 2020 at 1:44 PM h...@infradead.org wrote:
>
> On Wed, Aug 05, 2020 at 07:35:28AM +, 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
On 2020/08/14 21:04, h...@infradead.org wrote:
> On Fri, Aug 14, 2020 at 08:27:13AM +, Damien Le Moal wrote:
>>>
>>> O_APPEND pretty much implies out of order, as there is no way for an
>>> application to know which thread wins the race to write the next chunk.
>>
>> Yes and no. If the
On Fri, Aug 14, 2020 at 08:27:13AM +, Damien Le Moal wrote:
> >
> > O_APPEND pretty much implies out of order, as there is no way for an
> > application to know which thread wins the race to write the next chunk.
>
> Yes and no. If the application threads do not synchronize their calls to
>
On 2020/08/14 17:14, h...@infradead.org wrote:
> On Wed, Aug 05, 2020 at 07:35:28AM +, 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
On Wed, Aug 05, 2020 at 07:35:28AM +, 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
>
On 2020/07/31 21:51, h...@infradead.org wrote:
> On Fri, Jul 31, 2020 at 10:16:49AM +, Damien Le Moal wrote:
>>>
>>> Let's keep semantics and implementation separate. For the case
>>> where we report the actual offset we need a size imitation and no
>>> short writes.
>>
>> OK. So the name of
On Fri, Jul 31, 2020 at 6:38 PM h...@infradead.org wrote:
>
> And FYI, this is what I'd do for a hacky aio-only prototype (untested):
>
>
> diff --git a/fs/aio.c b/fs/aio.c
> index 91e7cc4a9f179b..42b1934e38758b 100644
> --- a/fs/aio.c
> +++ b/fs/aio.c
> @@ -1438,7 +1438,10 @@ static void
And FYI, this is what I'd do for a hacky aio-only prototype (untested):
diff --git a/fs/aio.c b/fs/aio.c
index 91e7cc4a9f179b..42b1934e38758b 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -1438,7 +1438,10 @@ static void aio_complete_rw(struct kiocb *kiocb, long
res, long res2)
}
On Fri, Jul 31, 2020 at 10:16:49AM +, Damien Le Moal wrote:
> >
> > Let's keep semantics and implementation separate. For the case
> > where we report the actual offset we need a size imitation and no
> > short writes.
>
> OK. So the name of the flag confused me. The flag name should
On 2020/07/31 18:41, h...@infradead.org wrote:
> On Fri, Jul 31, 2020 at 09:34:50AM +, Damien Le Moal wrote:
>> Sync writes are done under the inode lock, so there cannot be other writers
>> at
>> the same time. And for the sync case, since the actual written offset is
>> necessarily equal to
On Fri, Jul 31, 2020 at 09:34:50AM +, Damien Le Moal wrote:
> Sync writes are done under the inode lock, so there cannot be other writers at
> the same time. And for the sync case, since the actual written offset is
> necessarily equal to the file size before the write, there is no need to
>
On Fri, Jul 31, 2020 at 1:44 PM Damien Le Moal wrote:
>
> On 2020/07/31 16:59, Kanchan Joshi wrote:
> > On Fri, Jul 31, 2020 at 12:29 PM Damien Le Moal
> > wrote:
> >>
> >> On 2020/07/31 15:45, h...@infradead.org wrote:
> >>> On Fri, Jul 31, 2020 at 06:42:10AM +, Damien Le Moal wrote:
>
On 2020/07/31 18:14, h...@infradead.org wrote:
> On Fri, Jul 31, 2020 at 08:14:22AM +, Damien Le Moal wrote:
>>
>>> This was one of the reason why we chose to isolate the operation by a
>>> different IOCB flag and not by IOCB_APPEND alone.
>>
>> For zonefs, the plan is:
>> * For the sync write
On Fri, Jul 31, 2020 at 08:14:22AM +, Damien Le Moal wrote:
>
> > This was one of the reason why we chose to isolate the operation by a
> > different IOCB flag and not by IOCB_APPEND alone.
>
> For zonefs, the plan is:
> * For the sync write case, zone append is always used.
> * For the
On 2020/07/31 16:59, Kanchan Joshi wrote:
> On Fri, Jul 31, 2020 at 12:29 PM Damien Le Moal wrote:
>>
>> On 2020/07/31 15:45, h...@infradead.org wrote:
>>> On Fri, Jul 31, 2020 at 06:42:10AM +, Damien Le Moal wrote:
> - We may not be able to use RWF_APPEND, and need exposing a new
>
On Fri, Jul 31, 2020 at 12:29 PM Damien Le Moal wrote:
>
> On 2020/07/31 15:45, h...@infradead.org wrote:
> > On Fri, Jul 31, 2020 at 06:42:10AM +, Damien Le Moal wrote:
> >>> - We may not be able to use RWF_APPEND, and need exposing a new
> >>> type/flag (RWF_INDIRECT_OFFSET etc.)
On Fri, Jul 31, 2020 at 12:12 PM Damien Le Moal wrote:
>
> On 2020/07/31 3:26, Kanchan Joshi wrote:
> > On Thu, Jul 30, 2020 at 11:24 PM Jens Axboe wrote:
> >>
> >> On 7/30/20 11:51 AM, Kanchan Joshi wrote:
> >>> On Thu, Jul 30, 2020 at 11:10 PM Pavel Begunkov
> >>> wrote:
>
> On
On 2020/07/31 15:45, h...@infradead.org wrote:
> On Fri, Jul 31, 2020 at 06:42:10AM +, 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
On Fri, Jul 31, 2020 at 06:42:10AM +, 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
On 2020/07/31 3:26, Kanchan Joshi wrote:
> On Thu, Jul 30, 2020 at 11:24 PM Jens Axboe wrote:
>>
>> On 7/30/20 11:51 AM, Kanchan Joshi wrote:
>>> On Thu, Jul 30, 2020 at 11:10 PM Pavel Begunkov
>>> wrote:
On 30/07/2020 20:16, Jens Axboe wrote:
> On 7/30/20 10:26 AM, Pavel Begunkov
On Thu, Jul 30, 2020 at 11:24 PM Jens Axboe wrote:
>
> On 7/30/20 11:51 AM, Kanchan Joshi wrote:
> > On Thu, Jul 30, 2020 at 11:10 PM Pavel Begunkov
> > wrote:
> >>
> >> On 30/07/2020 20:16, Jens Axboe wrote:
> >>> On 7/30/20 10:26 AM, Pavel Begunkov wrote:
> On 30/07/2020 19:13, Jens
On 7/30/20 11:51 AM, Kanchan Joshi wrote:
> On Thu, Jul 30, 2020 at 11:10 PM Pavel Begunkov
> wrote:
>>
>> On 30/07/2020 20:16, Jens Axboe wrote:
>>> On 7/30/20 10:26 AM, Pavel Begunkov wrote:
On 30/07/2020 19:13, Jens Axboe wrote:
> On 7/30/20 10:08 AM, Pavel Begunkov wrote:
>> On
On Thu, Jul 30, 2020 at 11:10 PM Pavel Begunkov wrote:
>
> On 30/07/2020 20:16, Jens Axboe wrote:
> > On 7/30/20 10:26 AM, Pavel Begunkov wrote:
> >> On 30/07/2020 19:13, Jens Axboe wrote:
> >>> On 7/30/20 10:08 AM, Pavel Begunkov wrote:
> On 27/07/2020 23:34, Jens Axboe wrote:
> > On
On 30/07/2020 20:16, Jens Axboe wrote:
> On 7/30/20 10:26 AM, Pavel Begunkov wrote:
>> On 30/07/2020 19:13, Jens Axboe wrote:
>>> On 7/30/20 10:08 AM, Pavel Begunkov wrote:
On 27/07/2020 23:34, Jens Axboe wrote:
> On 7/27/20 1:16 PM, Kanchan Joshi wrote:
>> On Fri, Jul 24, 2020 at
On 7/30/20 10:26 AM, Pavel Begunkov wrote:
> On 30/07/2020 19:13, Jens Axboe wrote:
>> On 7/30/20 10:08 AM, Pavel Begunkov wrote:
>>> On 27/07/2020 23:34, Jens Axboe wrote:
On 7/27/20 1:16 PM, Kanchan Joshi wrote:
> On Fri, Jul 24, 2020 at 10:00 PM Jens Axboe wrote:
>>
>> On
On 30/07/2020 19:13, Jens Axboe wrote:
> On 7/30/20 10:08 AM, Pavel Begunkov wrote:
>> On 27/07/2020 23:34, Jens Axboe wrote:
>>> On 7/27/20 1:16 PM, Kanchan Joshi wrote:
On Fri, Jul 24, 2020 at 10:00 PM Jens Axboe wrote:
>
> On 7/24/20 9:49 AM, Kanchan Joshi wrote:
>> diff --git
On 7/30/20 10:08 AM, Pavel Begunkov wrote:
> On 27/07/2020 23:34, Jens Axboe wrote:
>> On 7/27/20 1:16 PM, Kanchan Joshi wrote:
>>> On Fri, Jul 24, 2020 at 10:00 PM Jens Axboe wrote:
On 7/24/20 9:49 AM, Kanchan Joshi wrote:
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index
On 27/07/2020 23:34, Jens Axboe wrote:
> On 7/27/20 1:16 PM, Kanchan Joshi wrote:
>> On Fri, Jul 24, 2020 at 10:00 PM Jens Axboe wrote:
>>>
>>> On 7/24/20 9:49 AM, Kanchan Joshi wrote:
diff --git a/fs/io_uring.c b/fs/io_uring.c
index 7809ab2..6510cf5 100644
--- a/fs/io_uring.c
On 24/07/2020 18:49, Kanchan Joshi wrote:
> From: SelvaKumar S
>
> Repurpose [cqe->res, cqe->flags] into cqe->res64 (signed) to report
> 64bit written-offset for zone-append. The appending-write which requires
> reporting written-location (conveyed by IOCB_ZONE_APPEND flag) is
> ensured not to
On 7/27/20 1:16 PM, Kanchan Joshi wrote:
> On Fri, Jul 24, 2020 at 10:00 PM Jens Axboe wrote:
>>
>> On 7/24/20 9:49 AM, Kanchan Joshi wrote:
>>> diff --git a/fs/io_uring.c b/fs/io_uring.c
>>> index 7809ab2..6510cf5 100644
>>> --- a/fs/io_uring.c
>>> +++ b/fs/io_uring.c
>>> @@ -1284,8 +1301,15 @@
On Fri, Jul 24, 2020 at 10:00 PM Jens Axboe wrote:
>
> On 7/24/20 9:49 AM, Kanchan Joshi wrote:
> > diff --git a/fs/io_uring.c b/fs/io_uring.c
> > index 7809ab2..6510cf5 100644
> > --- a/fs/io_uring.c
> > +++ b/fs/io_uring.c
> > @@ -1284,8 +1301,15 @@ static void __io_cqring_fill_event(struct
On 7/24/20 9:49 AM, Kanchan Joshi wrote:
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 7809ab2..6510cf5 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -1284,8 +1301,15 @@ static void __io_cqring_fill_event(struct io_kiocb
> *req, long res, long cflags)
> cqe =
From: SelvaKumar S
Repurpose [cqe->res, cqe->flags] into cqe->res64 (signed) to report
64bit written-offset for zone-append. The appending-write which requires
reporting written-location (conveyed by IOCB_ZONE_APPEND flag) is
ensured not to be a short-write; this avoids the need to report
39 matches
Mail list logo
