Some uncomformity between the realization of the RHEL5Beta1 and the RFC1813

Some uncomformity between the realization of the RHEL5Beta1 and the RFC1813

[xurui]

[-- Attachment #1.1: Type: text/plain, Size: 2229 bytes --]

Hi:

      I hope this is the right list for this.

      My group is engaged in the NFSV3 protocol comformance test.it means ,we want to prove whether the realization of the NFSV3 protocol in all versions of the REDHAT is according to the RFC(here ,we use RFC 1813).

      When we test the COMMIT procedure in the realization of the REDHAT with the kernel RHEL5Beta1 ,which is used to commit cached data on a server to stable storage,we find some inconsistent definitions between the kernel RHEL5Beta1 and RFC1813.In the RFC1813, it defines the COMMIT package as follows:

 struct COMMIT3args {
           nfs_fh3    file;
           offset3    offset;
           count3     count;
      };

      struct COMMIT3resok {
           wcc_data   file_wcc;
           writeverf3 verf;
      };

      struct COMMIT3resfail {
           wcc_data   file_wcc;
      };

 DESCRIPTION:

    offset
         The position within the file at which the flush is to
         begin.  An offset of 0 means to flush data starting at
         the beginning of the file.

      count
         The number of bytes of data to flush. If count is 0, a
         flush from offset to the end of file is done.

    

 

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,but it returen ok and flushed all data to the stable storage. the source code of the kernel RHEL5Betal are researched .In the file linux/mm/filemap.c _filemap_fdatawrite_range funtion defines the range of the data to be flushed ,the start position is set to zero,and the end position is constant LLONG_MAX(9223372036054775007).the function calling procedure as follows:

nfsd3_proc_commit()

          |--nfsd_commit()

|--nfsd_sync()

  |--nfsd_dosync()

    |--filemap_fdatawrite()

      |--_filemap_fdatawrite()

       |--_filemap_fdatawrite_range (..start,end..)

    

      We can't understand why kernel design them like this,why they set the range of the data to be flushed as zero to LLONG_MAX ,which is constant.



thanks 

 xurui

20061101

 

 

 

    

 

 

[-- Attachment #1.2: Type: text/html, Size: 10343 bytes --]

[-- Attachment #2: Type: text/plain, Size: 373 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Some uncomformity between the realization of the RHEL5Beta1 and the RFC1813

[J. Bruce Fields]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Some uncomformity between the realization of the kernel and the RFC1813

[xurui]

> 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" <bfields@fieldses.org>
To: "xurui" <xur@nanjing-fnst.com>
Cc: <nfs@lists.sourceforge.net>
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Some uncomformity between the realization of the kernel and the RFC1813

[Peter Staubach]

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