Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 223756

Summary: Some uncomformity between the realization of the newest kernel and the RFC1813
Product: Red Hat Enterprise Linux 5 Reporter: Xuui <xur>
Component: kernelAssignee: Peter Staubach <staubach>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: jlayton, steved
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-09 11:48:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Xuui 2007-01-22 07:47:23 UTC

      I have some question,Can you help me?

      My group is engaged in the NFSV3 protocol comformance 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  newest kernel  ,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;


         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.

         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 newest kernel  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:







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




Comment 1 Peter Staubach 2007-08-09 11:48:57 UTC
This is not a bug.  The server flushed all data within the range specified
by the client.

There isn't anything in the protocol specification about limiting the byte
range to the size of the file.