> 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.
Thank you for your reply.
----- Original Message -----
From: "J. Bruce Fields" <[email protected]>
To: "xurui" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, November 01, 2006 10:50 AM
Subject: Re: [NFS] Some uncomformity between the realization of the
RHEL5Beta1 and the RFC1813
> On Wed, Nov 01, 2006 at 10:41:03AM +0800, xurui wrote:
>> struct COMMIT3args { nfs_fh3 file; offset3 offset; count3
>> count; };
> ...
>>
>>
>> When we send the package with the sum of the augment count and offset
>> larger than the file size ,which will lead to the overflow ,we assumed
>> that nfs server will return fail message,
>
> Why do you assume that?
>
> 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?
>
> --b.
-------------------------------------------------------------------------
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs