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