* [PATCH] [fs/9p] Let the read retry on short reads. @ 2010-08-17 18:46 Venkateswararao Jujjuri (JV) 2010-08-17 19:45 ` [V9fs-developer] " Latchesar Ionkov 0 siblings, 1 reply; 6+ messages in thread From: Venkateswararao Jujjuri (JV) @ 2010-08-17 18:46 UTC (permalink / raw) To: v9fs-developer; +Cc: linux-fsdevel, Venkateswararao Jujjuri (JV) A simple fix to retry on short reads. Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com> --- fs/9p/vfs_file.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c index 2695491..cae984d 100644 --- a/fs/9p/vfs_file.c +++ b/fs/9p/vfs_file.c @@ -166,7 +166,7 @@ v9fs_file_readn(struct file *filp, char *data, char __user *udata, u32 count, offset += n; count -= n; total += n; - } while (count > 0 && n == size); + } while (count > 0); if (n < 0) total = n; -- 1.6.5.2 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [V9fs-developer] [PATCH] [fs/9p] Let the read retry on short reads. 2010-08-17 18:46 [PATCH] [fs/9p] Let the read retry on short reads Venkateswararao Jujjuri (JV) @ 2010-08-17 19:45 ` Latchesar Ionkov 2010-08-17 20:10 ` Venkateswararao Jujjuri (JV) 0 siblings, 1 reply; 6+ messages in thread From: Latchesar Ionkov @ 2010-08-17 19:45 UTC (permalink / raw) To: Venkateswararao Jujjuri (JV); +Cc: v9fs-developer, linux-fsdevel What problem does that change solve? It adds an additional call when EOF is reached. The way most user apps are written, that'll mean two calls that return Rread count 0. I was thinking of doing a similar change, but decided against it. Thanks, Lucho On Tue, Aug 17, 2010 at 12:46 PM, Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com> wrote: > A simple fix to retry on short reads. > > Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com> > --- > fs/9p/vfs_file.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c > index 2695491..cae984d 100644 > --- a/fs/9p/vfs_file.c > +++ b/fs/9p/vfs_file.c > @@ -166,7 +166,7 @@ v9fs_file_readn(struct file *filp, char *data, char __user *udata, u32 count, > offset += n; > count -= n; > total += n; > - } while (count > 0 && n == size); > + } while (count > 0); > > if (n < 0) > total = n; > -- > 1.6.5.2 > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > V9fs-developer mailing list > V9fs-developer@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/v9fs-developer > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [V9fs-developer] [PATCH] [fs/9p] Let the read retry on short reads. 2010-08-17 19:45 ` [V9fs-developer] " Latchesar Ionkov @ 2010-08-17 20:10 ` Venkateswararao Jujjuri (JV) 2010-08-17 20:39 ` Latchesar Ionkov 0 siblings, 1 reply; 6+ messages in thread From: Venkateswararao Jujjuri (JV) @ 2010-08-17 20:10 UTC (permalink / raw) To: Latchesar Ionkov; +Cc: v9fs-developer, linux-fsdevel Latchesar Ionkov wrote: > What problem does that change solve? It adds an additional call when > EOF is reached. The way most user apps are written, that'll mean two > calls that return Rread count 0. > > I was thinking of doing a similar change, but decided against it. Yeah I ran into the issue when tried with o_direct and dd. Can we depend on the application retrying? Yes I also observed the behavior you are mentioning (2 Rreads returning 0) Wondering if we have a better way to address this. Thanks, JV > > Thanks, > Lucho > > On Tue, Aug 17, 2010 at 12:46 PM, Venkateswararao Jujjuri (JV) > <jvrao@linux.vnet.ibm.com> wrote: >> A simple fix to retry on short reads. >> >> Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com> >> --- >> fs/9p/vfs_file.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c >> index 2695491..cae984d 100644 >> --- a/fs/9p/vfs_file.c >> +++ b/fs/9p/vfs_file.c >> @@ -166,7 +166,7 @@ v9fs_file_readn(struct file *filp, char *data, char __user *udata, u32 count, >> offset += n; >> count -= n; >> total += n; >> - } while (count > 0 && n == size); >> + } while (count > 0); >> >> if (n < 0) >> total = n; >> -- >> 1.6.5.2 >> >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> V9fs-developer mailing list >> V9fs-developer@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/v9fs-developer >> ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [V9fs-developer] [PATCH] [fs/9p] Let the read retry on short reads. 2010-08-17 20:10 ` Venkateswararao Jujjuri (JV) @ 2010-08-17 20:39 ` Latchesar Ionkov 2010-08-23 16:11 ` Eric Van Hensbergen 0 siblings, 1 reply; 6+ messages in thread From: Latchesar Ionkov @ 2010-08-17 20:39 UTC (permalink / raw) To: Venkateswararao Jujjuri (JV); +Cc: v9fs-developer, linux-fsdevel The only solution I can think of is to use the iounit value the file server returns (and not the msize as we do now). If iounit is 0, allow short reads, if iounit is more than zero and the read returns less that the iounit, don't try anymore. This kind of passes the problem to the file server, but I guess that's the right place to solve it anyway. Thanks, Lucho On Tue, Aug 17, 2010 at 2:10 PM, Venkateswararao Jujjuri (JV) <jvrao@linux.vnet.ibm.com> wrote: > Latchesar Ionkov wrote: >> What problem does that change solve? It adds an additional call when >> EOF is reached. The way most user apps are written, that'll mean two >> calls that return Rread count 0. >> >> I was thinking of doing a similar change, but decided against it. > > Yeah I ran into the issue when tried with o_direct and dd. > > Can we depend on the application retrying? > Yes I also observed the behavior you are mentioning (2 Rreads returning 0) > Wondering if we have a better way to address this. > > Thanks, > JV > >> >> Thanks, >> Lucho >> >> On Tue, Aug 17, 2010 at 12:46 PM, Venkateswararao Jujjuri (JV) >> <jvrao@linux.vnet.ibm.com> wrote: >>> A simple fix to retry on short reads. >>> >>> Signed-off-by: Venkateswararao Jujjuri <jvrao@linux.vnet.ibm.com> >>> --- >>> fs/9p/vfs_file.c | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/fs/9p/vfs_file.c b/fs/9p/vfs_file.c >>> index 2695491..cae984d 100644 >>> --- a/fs/9p/vfs_file.c >>> +++ b/fs/9p/vfs_file.c >>> @@ -166,7 +166,7 @@ v9fs_file_readn(struct file *filp, char *data, char __user *udata, u32 count, >>> offset += n; >>> count -= n; >>> total += n; >>> - } while (count > 0 && n == size); >>> + } while (count > 0); >>> >>> if (n < 0) >>> total = n; >>> -- >>> 1.6.5.2 >>> >>> >>> ------------------------------------------------------------------------------ >>> This SF.net email is sponsored by >>> >>> Make an app they can't live without >>> Enter the BlackBerry Developer Challenge >>> http://p.sf.net/sfu/RIM-dev2dev >>> _______________________________________________ >>> V9fs-developer mailing list >>> V9fs-developer@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/v9fs-developer >>> > > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [V9fs-developer] [PATCH] [fs/9p] Let the read retry on short reads. 2010-08-17 20:39 ` Latchesar Ionkov @ 2010-08-23 16:11 ` Eric Van Hensbergen 2010-08-23 16:43 ` Latchesar Ionkov 0 siblings, 1 reply; 6+ messages in thread From: Eric Van Hensbergen @ 2010-08-23 16:11 UTC (permalink / raw) To: Latchesar Ionkov Cc: Venkateswararao Jujjuri (JV), linux-fsdevel, v9fs-developer On Tue, Aug 17, 2010 at 3:39 PM, Latchesar Ionkov <lucho@ionkov.net> wrote: > The only solution I can think of is to use the iounit value the file > server returns (and not the msize as we do now). If iounit is 0, allow > short reads, if iounit is more than zero and the read returns less > that the iounit, don't try anymore. > > This kind of passes the problem to the file server, but I guess that's > the right place to solve it anyway. > What's the potential impact on existing serves? What does Plan 9 expect? read(5) says: The count field in the reply indicates the number of bytes returned. This may be less than the requested amount. If the offset field is greater than or equal to the number of bytes in the file, a count of zero will be returned. I'd say if we wanted to do something different, I would need to be conditional by 9p2000.u/9p2000.L -- I don't want to break existing servers/clients that might rely on this behavior to frame messages (like pipes, the IP stack, etc.) -eric ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [V9fs-developer] [PATCH] [fs/9p] Let the read retry on short reads. 2010-08-23 16:11 ` Eric Van Hensbergen @ 2010-08-23 16:43 ` Latchesar Ionkov 0 siblings, 0 replies; 6+ messages in thread From: Latchesar Ionkov @ 2010-08-23 16:43 UTC (permalink / raw) To: Eric Van Hensbergen Cc: Venkateswararao Jujjuri (JV), linux-fsdevel, v9fs-developer The potential impact is that if the existing server returns iounit==0, there will be two Rread count 0. Which is perfectly fine with 9P, just a bit slower. I am not sure how Plan9 handles the case. Thanks, Lucho On Mon, Aug 23, 2010 at 10:11 AM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > On Tue, Aug 17, 2010 at 3:39 PM, Latchesar Ionkov <lucho@ionkov.net> wrote: >> The only solution I can think of is to use the iounit value the file >> server returns (and not the msize as we do now). If iounit is 0, allow >> short reads, if iounit is more than zero and the read returns less >> that the iounit, don't try anymore. >> >> This kind of passes the problem to the file server, but I guess that's >> the right place to solve it anyway. >> > > What's the potential impact on existing serves? What does Plan 9 expect? > > read(5) says: > The count field in the reply indicates the number of bytes returned. > This may be less than the requested amount. If the offset field is > greater than or equal to the number of bytes in the file, a count of > zero will be returned. > > I'd say if we wanted to do something different, I would need to be > conditional by 9p2000.u/9p2000.L -- I don't want to break existing > servers/clients that might rely on this behavior to frame messages > (like pipes, the IP stack, etc.) > > -eric > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-08-23 16:43 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-08-17 18:46 [PATCH] [fs/9p] Let the read retry on short reads Venkateswararao Jujjuri (JV) 2010-08-17 19:45 ` [V9fs-developer] " Latchesar Ionkov 2010-08-17 20:10 ` Venkateswararao Jujjuri (JV) 2010-08-17 20:39 ` Latchesar Ionkov 2010-08-23 16:11 ` Eric Van Hensbergen 2010-08-23 16:43 ` Latchesar Ionkov
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.