From: Petr Vandrovec <vandrove@vc.cvut.cz>
To: Avishay Traeger <atraeger@cs.sunysb.edu>
Cc: Xin Zhao <uszhaoxin@gmail.com>, Chris Wedgwood <cw@f00f.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org
Subject: Re: HELP! vfs_readv() issue
Date: Thu, 18 May 2006 20:12:44 +0200 [thread overview]
Message-ID: <446CB91C.50302@vc.cvut.cz> (raw)
In-Reply-To: <1147975279.3073.4.camel@85.65.211.169.dynamic.barak-online.net>
Avishay Traeger wrote:
> On Wed, 2006-05-17 at 17:44 -0400, Xin Zhao wrote:
>
>>Thank you for your care. What I am trying to do is to rewrite NFS in
>>the virtual machine environment so that network communication can be
>>replaced with inter-VM communication.
>>
>>But after I remove the original rpc stuff, I ran into some strange
>>problem, including this one. Interesting thing is that I noticed that
>>even with standard NFS implementation, it is still possible that
>>nfsd_read() return resp->count to be 0. At this time, eof is also
>>equal to 1. This seems to be right since NFSD already reach the end of
>>the file. But question is since 0 byte is read this time, NFS should
>>detect EOF in previous read. Why need one more read?
>>
>>Xin
>
>
> How are you reading the file? Some programs (I believe 'cat' is one of
> them) will read a file until 0 is returned. Try writing a small C
> program to read a file until EOF and see if the behavior changes.
Returning 0 from read() is only situation when you can be sure you are at the
end of file. If you get short read(), it may be short due to EOF, but it may be
short also because some error was hit - EIO and EFAULT are two which can occur
almost always. And only next read will either return that error (or some other
error, or success if error condition disappeared meanwhile), or zero if it is
really EOF.
Petr
prev parent reply other threads:[~2006-05-18 18:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-15 23:57 HELP! vfs_readv() issue Xin Zhao
2006-05-16 4:31 ` Chris Wedgwood
2006-05-17 21:44 ` Xin Zhao
2006-05-18 18:00 ` Avishay Traeger
2006-05-18 18:12 ` Petr Vandrovec [this message]
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=446CB91C.50302@vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=atraeger@cs.sunysb.edu \
--cc=cw@f00f.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=uszhaoxin@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox