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 - Some uncomformity between the realization of the newest kernel and the RFC1813
Summary: Some uncomformity between the realization of the newest kernel and the RFC1813
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Peter Staubach
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-01-22 07:47 UTC by Xuui
Modified: 2007-11-30 22:07 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-08-09 11:48:57 UTC
Target Upstream Version:

Attachments (Terms of Use)

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.

Note You need to log in before you can comment on or make changes to this bug.