From: Peter Staubach <staubach@redhat.com>
To: xurui <xur@nanjing-fnst.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>, nfs@lists.sourceforge.net
Subject: Re: Some uncomformity between the realization of the kernel and the RFC1813
Date: Wed, 01 Nov 2006 09:21:35 -0500 [thread overview]
Message-ID: <4548AD6F.7020109@redhat.com> (raw)
In-Reply-To: <009301c6fd67$77a68b60$8904a8c0@xurui>
xurui wrote:
>> Why do you assume that?
>>
> Our assumption is according to the RFC1813(Page 34) described as follows:
> "If the server receives a full file COMMIT request, that is starting at
> offset 0 and count 0, it should do the equivalent of fsync()'ing the file.
> Otherwise, it should arrange to have the cached data in the range specified
> by offset and count to be flushed to stable storage."
>
> It shows that when we set the offset and count, the server should cached the
> data among this arrange, not the full data in the cache. We don't know why
> kernel design it like this .
>
>
>> That doesn't sound like the right behavior to me. What if the file has
>> been truncated on the server without the client's knowledge? Isn't it
>> better in that case to flush out whatever range remains instead of
>> failing the commit?
>>
>
>
> We assume that when server receives these packages, it may return fail
> message. or others, My question is that if we set the legal offset and count
> and their sum is smaller than the file size , the server still flush all
> data to the stable storage, not the data specified by the count and offset.
> So we believe that some unconformity between the realization of the kernel
> and the RFC1813.
Please be aware that in this respect, RFC1813 describes the minimal that
a server must do. If the server implementation decides to write more cached
data to stable storage than it was requested to do, then it is free to
do so.
All of the cached data at the server must be written to stable storage at
some time or another and writing it sooner as opposed to later is better
for stability purposes.
The intent is that the server do at least what was requested, not less.
More
can be good if it does not significantly impact performance and can
potentially
lead to better performance and/or a simpler implementation. A simpler
implementation can often lead to a more stable implementation.
Thanx...
ps
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
prev parent reply other threads:[~2006-11-01 14:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-01 2:41 Some uncomformity between the realization of the RHEL5Beta1 and the RFC1813 xurui
2006-11-01 2:50 ` J. Bruce Fields
2006-11-01 3:40 ` Some uncomformity between the realization of the kernel " xurui
2006-11-01 14:21 ` Peter Staubach [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=4548AD6F.7020109@redhat.com \
--to=staubach@redhat.com \
--cc=bfields@fieldses.org \
--cc=nfs@lists.sourceforge.net \
--cc=xur@nanjing-fnst.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 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.