Bug 223756 - Some uncomformity between the realization of the newest kernel and the RFC1813
Some uncomformity between the realization of the newest kernel and the RFC1813
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Staubach
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-01-22 02:47 EST by Xuui
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-09 07:48:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Xuui 2007-01-22 02:47:23 EST
Hi:

      I have some question,Can you help me?

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

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

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
Comment 1 Peter Staubach 2007-08-09 07:48:57 EDT
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.