All of lore.kernel.org
 help / color / mirror / Atom feed
From: JeffleXu <jefflexu@linux.alibaba.com>
To: Jeff Layton <jlayton@kernel.org>,
	dhowells@redhat.com, xiang@kernel.org, chao@kernel.org,
	linux-cachefs@redhat.com, linux-erofs@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/2] erofs: switch to prepare_ondemand_read() in fscache mode
Date: Fri, 4 Nov 2022 20:20:09 +0800	[thread overview]
Message-ID: <6064150a-7517-c0e1-72bb-e1a8adcfae74@linux.alibaba.com> (raw)
In-Reply-To: <2e2eceeb11972462bb9161a73c00a9c77f8af8d2.camel@kernel.org>



On 11/4/22 7:46 PM, Jeff Layton wrote:
> On Fri, 2022-11-04 at 15:26 +0800, Jingbo Xu wrote:
>> Switch to prepare_ondemand_read() interface and a self-contained request
>> completion to get rid of netfs_io_[request|subrequest].
>>
>> The whole request will still be split into slices (subrequest) according
>> to the cache state of the backing file.  As long as one of the
>> subrequests fails, the whole request will be marked as failed. Besides
>> it will not retry for short read.  Similarly the whole request will fail
>> if that really happens. 
>>
> 
> That's sort of nasty. The kernel can generally give you a short read for
> all sorts of reasons, some of which may have nothing to do with the
> underlying file or filesystem.
> 
> Passing an error back to an application on a short read is probably not
> what you want to do here. The usual thing to do is just to return what
> you can, and let the application redrive the request if it wants.
> 

Yeah, thanks for your comment. We can fix this either in current
patchset or a separate series. As we just discussed on IRC, we will fix
in the following series.



-- 
Thanks,
Jingbo

WARNING: multiple messages have this Message-ID (diff)
From: JeffleXu <jefflexu@linux.alibaba.com>
To: Jeff Layton <jlayton@kernel.org>,
	dhowells@redhat.com, xiang@kernel.org, chao@kernel.org,
	linux-cachefs@redhat.com, linux-erofs@lists.ozlabs.org
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] erofs: switch to prepare_ondemand_read() in fscache mode
Date: Fri, 4 Nov 2022 20:20:09 +0800	[thread overview]
Message-ID: <6064150a-7517-c0e1-72bb-e1a8adcfae74@linux.alibaba.com> (raw)
In-Reply-To: <2e2eceeb11972462bb9161a73c00a9c77f8af8d2.camel@kernel.org>



On 11/4/22 7:46 PM, Jeff Layton wrote:
> On Fri, 2022-11-04 at 15:26 +0800, Jingbo Xu wrote:
>> Switch to prepare_ondemand_read() interface and a self-contained request
>> completion to get rid of netfs_io_[request|subrequest].
>>
>> The whole request will still be split into slices (subrequest) according
>> to the cache state of the backing file.  As long as one of the
>> subrequests fails, the whole request will be marked as failed. Besides
>> it will not retry for short read.  Similarly the whole request will fail
>> if that really happens. 
>>
> 
> That's sort of nasty. The kernel can generally give you a short read for
> all sorts of reasons, some of which may have nothing to do with the
> underlying file or filesystem.
> 
> Passing an error back to an application on a short read is probably not
> what you want to do here. The usual thing to do is just to return what
> you can, and let the application redrive the request if it wants.
> 

Yeah, thanks for your comment. We can fix this either in current
patchset or a separate series. As we just discussed on IRC, we will fix
in the following series.



-- 
Thanks,
Jingbo

  reply	other threads:[~2022-11-04 12:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-04  7:26 [PATCH 0/2] fscache,cachefiles: add prepare_ondemand_read() interface Jingbo Xu
2022-11-04  7:26 ` Jingbo Xu
2022-11-04  7:26 ` [PATCH 1/2] fscache,cachefiles: add prepare_ondemand_read() callback Jingbo Xu
2022-11-04  7:26   ` Jingbo Xu
2022-11-04 11:18   ` Jeff Layton
2022-11-04 11:18     ` Jeff Layton
2022-11-04 12:22     ` JeffleXu
2022-11-04 12:22       ` JeffleXu
2022-11-04  7:26 ` [PATCH 2/2] erofs: switch to prepare_ondemand_read() in fscache mode Jingbo Xu
2022-11-04  7:26   ` Jingbo Xu
2022-11-04 11:46   ` Jeff Layton
2022-11-04 11:46     ` Jeff Layton
2022-11-04 12:20     ` JeffleXu [this message]
2022-11-04 12:20       ` JeffleXu

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=6064150a-7517-c0e1-72bb-e1a8adcfae74@linux.alibaba.com \
    --to=jefflexu@linux.alibaba.com \
    --cc=chao@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=jlayton@kernel.org \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=xiang@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.