All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Van Hensbergen <ericvh@gmail.com>
To: Latchesar Ionkov <lucho@ionkov.net>
Cc: "Venkateswararao Jujjuri (JV)" <jvrao@linux.vnet.ibm.com>,
	linux-fsdevel@vger.kernel.org,
	v9fs-developer@lists.sourceforge.net
Subject: Re: [V9fs-developer] [PATCH] [fs/9p] Let the read retry on short reads.
Date: Mon, 23 Aug 2010 11:11:11 -0500	[thread overview]
Message-ID: <AANLkTik3FbfEK7BbHL428+DWoStYD-PrF0MzuhEGtbav@mail.gmail.com> (raw)
In-Reply-To: <AANLkTi=at2VXf8ZaBqFY9ag9V0i-Q87Ky8iGQ7SD7ptk@mail.gmail.com>

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

  reply	other threads:[~2010-08-23 16:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2010-08-23 16:43         ` Latchesar Ionkov

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=AANLkTik3FbfEK7BbHL428+DWoStYD-PrF0MzuhEGtbav@mail.gmail.com \
    --to=ericvh@gmail.com \
    --cc=jvrao@linux.vnet.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=v9fs-developer@lists.sourceforge.net \
    /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.