RE:

RE:

[Qin's Yanjun]

How are you today and your family? I require your attention and honest
co-operation about some issues which i will really want to discuss with you
which.  Looking forward to read from you soon.  

Qin's


______________________________

Sky Silk, http://aknet.kz

Re:

[Amos Kalonzo]

Attn:

I am wondering why You haven't respond to my email for some days now.
reference to my client's contract balance payment of (11.7M,USD)
Kindly get back to me for more details.

Best Regards

Amos Kalonzo

Re:

[Richard Wong]

I have a business proposal I would like to share with you, on your response I'll email you with more details.

Regards,
Richard Wong

(no subject)

[tigran.mkrtchyan]

to me it's unclear, why a SETATTR  always follows an OPEN, even in case of
EXCLUSIVE4_1. With this fix, I get desired behavior.

Tigran.

Re:

[Trond Myklebust]

On Feb 23, 2014, at 11:22, tigran.mkrtchyan@desy.de wrote:

> to me it's unclear, why a SETATTR  always follows an OPEN, even in case of
> EXCLUSIVE4_1. With this fix, I get desired behavior.

Yes, but that fix risks incurring an NFS4ERR_INVAL from which we cannot recover because it does not include the mandatory check for the allowed set of attributes.
Please see RFC5661 section 18.16.3 about the client side use of ‘suppattr_exclcreat’ .

Cheers,
  Trond

Re:

[Mkrtchyan, Tigran]

----- Original Message -----
> From: "Trond Myklebust" <trondmy@gmail.com>
> To: "Tigran Mkrtchyan" <tigran.mkrtchyan@desy.de>
> Cc: "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
> Sent: Sunday, February 23, 2014 5:41:26 PM
> Subject: Re:
> 
> 
> On Feb 23, 2014, at 11:22, tigran.mkrtchyan@desy.de wrote:
> 
> > to me it's unclear, why a SETATTR  always follows an OPEN, even in case of
> > EXCLUSIVE4_1. With this fix, I get desired behavior.
> 
> Yes, but that fix risks incurring an NFS4ERR_INVAL from which we cannot
> recover because it does not include the mandatory check for the allowed set
> of attributes.
> Please see RFC5661 section 18.16.3 about the client side use of
> ‘suppattr_exclcreat’ .

Yes, I noticed, that client never query that attribute. I will check a
possibility to add a check for suppattr_exclcreat as well.

Tigran.

> 
> Cheers,
>   Trond

nfs-utils-1.1.3 released.

[Steve Dickson]

I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
issues accessing my kernel.org account so for the moment the 
tar ball is only available on SourceForge:

     http://sourceforge.net/projects/nfs

As usual the tree is at:
    git://linux-nfs.org/nfs-utils

Here is the change log for this release:

commit 7f6ca07a8836dbdf30a227580441b99607639fd4
Author: Martin Leisner <Martin.Leisner@xerox.com>
Date:   Fri Jul 25 14:50:06 2008 -0400

    showmount issues
    
    The connect_nb() routne returns zero for success and a negative
    value for failure which was not being interpreted correctly
    by the getport() routine. This patch fixes that problem.
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit eddfbf7ac8ecd3f17dc295df6c1dac4bbc6ca846
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Fri Jul 25 14:31:18 2008 -0400

    nfs(5) man page: Add documentation for the "mountproto=" option
    
    Looks like mountproto= was never documented in nfs(5).  Add a paragraph
    that describes it in the "nfs mount options" section.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit cf8a5cbe7f6e6ae546c3e48710b657e3d940c7fb
Author: Steve Dickson <steved@redhat.com>
Date:   Fri Jul 25 14:15:47 2008 -0400

    sm-notify: perform DNS lookup in the background.
    
    If an NFS server has no network connectivity when it reboots,
    it will block in sm-notify waiting for DNS lookup for a potentially
    large number of hosts.  This is not helpful and just annoys the
    sysadmin.
    
    So do the DNS lookup in the backgrounded phase of sm-notify,
    before sending off the NOTIFY requests.
    
    Acked-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit ba8dd9533e647b70d6e46beed3dcd8d8036b02af
Author: Neil Brown <neilb@suse.de>
Date:   Wed Jul 16 13:28:52 2008 -0400

    If portmap is not listening on UDP (as apparently happens with
    MS-Windows-Server2003R2SP2), then nfs mounts have to be mounted
    with -o mountproto=tcp to succeed.
    
    In this case a umount will still try UDP and will fail to contact the
    server.  It will still succeed with the local unmount (after a
    timeout) but exits with a non-zero exit status.  This causes
    /bin/mount to retry so we get a strange error about the filesystem
    not being mounted.
    
    So:
      get umount to use tcp if "mountproto=tcp" appears in mtab
      ignore any failure message from the server that would overwrite
         a success message from the local umount syscall.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 8508942e7244017325690e2d0c17429fa0cb9873
Author: Neil Brown <neilb@suse.de>
Date:   Wed Jul 16 13:15:46 2008 -0400

    If an NFS server is only listening on TCP for portmap (as apparently
    MS-Windows-Server2003R2SP2 does), mount doesn't cope.  There is retry
    logic in case the initial choice of version/etc doesn't work, but it
    doesn't cope with mountd needing tcp.
    So:
      Fix probe_port so that a TIMEDOUT error doesn't simply abort
        but probes with other protocols (e.g. tcp).
      Fix rewrite_mount_options to extract the mountproto option before
        doing a probe, then set mountproto  (and mount prot) based
        on the result.
    
    Signed-off-by: Neil Brown <neilb@suse.de>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 8e158aa65577b96494eaa94c4983eed1449116dc
Author: Steve Dickson <steved@redhat.com>
Date:   Tue Jul 15 14:43:00 2008 -0400

    It appears that a recent glibc update now enforces the requirement for a mode
    parameter for open calls with the O_CREAT flag set.  nfs-utils support code
    defines a function xflock used by exportfs and mountd that calls open with
    O_CREAT but no mode parameter.  This causes exportfs and mountd to dump core,
    with the error message:
    *** invalid open64 call: O_CREAT without mode ***:rpc.mountd terminated
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 8dfb9661a132a206c10067f40e274cf797dab1b2
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:59:00 2008 -0400

    Clean up: Include the bare minimum of legacy RPC headers in
    utils/mount/network.h.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 1a1d3757d8881000496b838ff7d1ede981e9c40d
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:57:10 2008 -0400

    Clean up: remove unneeded headers from utils/mount/stropts.c.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 93cfabb56a0b85cffca9c75cfac59e687157d0cc
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:55:36 2008 -0400

    Clean up: rename a couple of functions in utils/mount/stropts.c to match
    the naming convention of the others.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit abb44f59bd004112a217011a2560dd7c7f94b5a2
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:53:50 2008 -0400

    Clean up: remove unused IPv4-only functions used by the text-based mount
    command.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 1d61a1116198714f50b081daecc663625124403d
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:51:07 2008 -0400

    Traditionally the mount command has looked for a ":" to separate the
    server's hostname from the export path in the mounted on device name,
    like this:
    
     mount server:/export /mounted/on/dir
    
    The server's hostname is "server" and the export path is "/export".
    
    You can also substitute a specific IPv4 network address for the server
    hostname, like this:
    
     mount 192.168.0.55:/export /mounted/on/dir
    
    Raw IPv6 addresses present a problem, however, because they look something
    like this:
    
     fe80::200:5aff:fe00:30b
    
    Note the use of colons.
    
    To get around the presence of colons, copy the Solaris convention used for
    raw NFS server IPv6 addresses, which is to wrap the raw IPv6 address with
    square brackets.  This is also suggested in RFC 4038.
    
    Introduce a new device name parser that can support traditional device
    names and square brackets.  Place the parser in a separate source file
    so both the mount and umount paths can derive the server's hostname and
    export pathname the same way.
    
    Bonus points: add a check for NFS URLs and display an appropriate error
    message in that case.  This is cleaner than failing with "unknown host:
    nfs".
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 586a66451679e25c47cb8cd65a0c6a0c44148920
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:38:53 2008 -0400

    Change the fix_mounthost_option() function to support resolving IPv6
    addresses.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 313dcf93f7a8351ff1664a3a7e2a964e02ea624a
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:37:07 2008 -0400

    Change the append_clientaddr_option() function to support sending either
    IPv4 or IPv6 addresses to the kernel via the "clientaddr=" option.
    
    If the mount.nfs4 command can't determine an appropriate callback address,
    it used to fail the mount request.  This new function simply sends an ANY
    address instead, so the mount request succeeds, but delegation is disabled.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 1adb0e018f57079c6e95a9bdbf904361354b0527
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:34:49 2008 -0400

    Change the append_addr_option() function to support sending either IPv4
    or IPv6 addresses to the kernel via the "addr=" option.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit da8a62dc65d2d105a3304dd41b6bdae5a5ddc742
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:33:32 2008 -0400

    There are three helpers that convert sockaddr-style addresses to text
    addresses, then construct mount options to pass these addresses to the
    kernel.  The tail of each of these helpers does exactly the same thing,
    so introduce a helper that handles the common code.
    
    Magically, the new helper supports IPv6 as well as IPv4.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 6ab9cdacd2ea314a837c7affb840aeeec620cb66
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:31:17 2008 -0400

    Introduce IPv6-enabled version of get_client_address.  The legacy mount
    command could use this eventually as well.
    
    If this new function fails to discover an appropriate callback address, it
    fills in an ANY address to indicate to the server that it should not call the
    client back (ie delegations are disabled in this case).
    
    The user can specify a callback address via the clientaddr= mount option in
    this case to enable delegation.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit ffb42f63d41542bd2dab4570248d18642e39ed48
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:27:15 2008 -0400

    Introduce two new functions to convert a sockaddr to a presentation format
    string and back.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 0ff226cb9dc9382c5215368a03a5bd3a69ee287a
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:23:58 2008 -0400

    Add #include directives for additional header files needed to support IPv6
    networking.  This is a separate patch so subsequent
    patches can be reordered without collision.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 20db952fc211b3444d83049f2d127da4f3ca6989
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 13:20:01 2008 -0400

    We want to continue to support building nfs-utils on systems that do not
    have IPv6-enabled RPC libraries and headers installed, so add a
    ./configure switch that allows distros to disable IPv6 functionality.
    
    This patch introduces the nfs-utils autotools configuration to the library
    and header dependencies that will be required in subsequent patches.
    Later patches can then be reordered more easily if these new dependencies
    are added in one heap.
    
    For now, --enable-ipv6 defaults to "no", so this patch should not result in
    any behavioral changes to the nfs-utils build process, by default.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 8bca04ebcc345784bf2ef29f0781e66157d76558
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 12:17:19 2008 -0400

    Currently the "-s" option is ignored by the text-based mount interface.  To
    notify the kernel that sloppy mount option parsing is needed, add "sloppy"
    to the string of mount options passed to the kernel.
    
    The 2.6.23 - 2.6.26 kernels will fail the mount if "sloppy" is present, as
    they won't recognize it.  To prevent them from ever seeing this option,
    have the mount command check the kernel version before appending the option.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 46c6575fe23a7468c17ec3329d956e9d3afe60e8
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 12:15:29 2008 -0400

    Lots of parts of nfs-utils already depend on getaddrinfo(3).
    
    We could find each instance where getaddrinfo(3) is invoked, wrap it with
    '#ifdef HAVE_GETADDRINFO', and provide equivalent logic without it, but that's
    a whole lot of work... and no-one has complained about this so far.
    
    So as a clean-up, let's simply add a hard dependency for it in configure.ac,
    and call it a day.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 1ca49510fd1742955330583f259db7faf501a5e5
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 12:13:10 2008 -0400

    Clean up: add the traditional pre-processor safety check in headers under
    utils/mount to prevent them from being included multiple times.
    
    For headers that already have this, use a more unique macro name to reduce the
    probability that some other header may use the same macro.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit d5a09b59916d4ef24b15e34eac394149cb7a641a
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 12:10:33 2008 -0400

    Moved the kernel version-ing code into a new version.h
    header file which allows the code to be shared
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 4f101548ef4990979400b7095e199c30204b100a
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 12:02:42 2008 -0400

    Introduce a new DNS resolver function in utils/mount/network.c that uses
    getaddrinfo(3), which supports AF_INET6, to resolve host names.
    
    Replace the guts of nfs_gethostbyname() with a call to the new function.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 52fe32278aee9f359d4ef6d1fab7be405ca0b193
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 11:59:03 2008 -0400

    The text-based mount command displays the rather inexplicable "mount:
    internal error" whenever it encounters a problem that is entirely
    unexpected by its designers.
    
    Let's beef that error message up to include instructions about reporting
    the problem, and fix the error code returned by the mount option rewriting
    logic so that also will no longer report "internal error".  An error in there
    should generally only occur if there was an invalid mount option specified.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 191d129672dacdc3ae3ac165cd1f2a877529d0ad
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Tue Jul 15 11:56:13 2008 -0400

    Updated both the mountstats and nfs-iostat scripts to used the
    proper abbreviation for kilobytes per second (kB/s).
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 58080798db321d025143df39c97f707ea994ba26
Author: Christiaan Welvaart <cjw@daneel.dyndns.org>
Date:   Tue Jul 15 11:42:42 2008 -0400

    Ported the create_mtab() routine from util-linux-ng as well
    some add_mtab() updates to better hand the instances where
    /etc/mtab does not exist or is not writable
    
    Signed-off-by: Christiaan Welvaart <cjw@daneel.dyndns.org>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit afa859b029d9cd15604ce7d5f88b5a205ea4c774
Author: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Date:   Tue Jul 15 10:12:39 2008 -0400

    The rpc.gssd scans for any suitable kerberos ticket. In cross-realm
    environment this may not be the desired behaviour. Therefore a new
    option, -R preferred realm, is presented so that the rpc.gssd prefers tickets
    from this realm. By default, the default realm is preferred.
    
    Signed-off-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
    Signed-off-by: Kevin Coffman <kwc@citi.umich.edu>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 1e1c7be98749fff054beec4bf67b436b58f6edac
Author: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Date:   Tue Jul 15 10:07:45 2008 -0400

    The default expiration of kernel gss contexts is the expiration
    of the Kerberos ticket used in its creation.  (For contexts
    created using the Kerberos mechanism.)  Thus kdestroy has
    no effect in nullifying the kernel context.
    
    This patch adds -t <timeout> option to rpc.gssd so that the client's
    administrator may specify a timeout for expiration of contexts in kernel.
    After this timeout, rpc.gssd is consulted to create a new context.
    
    By default, timeout is 0 (i.e., no timeout at all) which follows the
    previous behavior.
    
    Signed-off-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
    Signed-off-by: Kevin Coffman <kwc@citi.umich.edu>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit b13f13b0f2ebdadc47eef8bf3fd4eb076e144fda
Author: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Date:   Tue Jul 15 10:02:49 2008 -0400

    gssd_setup_krb5_user_gss_ccache must return an error if no usable cache is
    found. Trying to use invalid default cache and continue is not good idea at all.
    
    Signed-off-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
    Signed-off-by: Kevin Coffman <kwc@citi.umich.edu>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 710765a87d599d95de51b79202ba3d82fd03ed95
Author: Steve Dickson <steved@redhat.com>
Date:   Wed Jun 25 09:23:45 2008 -0400

    When a FQDN exists in /var/lib/nfs/rmtab it causes
    the exportfs command to seg fault due to the nfs_export pointer
    not being allocated. Reworking the parentheses in rmtab_read()
    so the htype variable is evaluated correctly fix the problem.
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 2ef57222b10a91f4b96a06808d05a47e8f4c14f7
Author: Tom Talpey <tmt@netapp.com>
Date:   Mon Jun 23 12:57:29 2008 -0400

    Add RDMA as a supported transport for reporting
    the mountstats statistics
    
    Signed-off-by: Tom Talpey <tmt@netapp.com>
    Acked-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit ba18e469a8507befdf8969c5ce7a25564744ae01
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Jun 23 12:56:14 2008 -0400

    The "nfs-iostat" utility is a Python program that extracts and displays NFS
    client performance information from /proc/self/mountstats.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 589a913e42476a965b686c9f2656b786eaae399e
Author: Tom Talpey <tmt@netapp.com>
Date:   Mon Jun 23 12:54:08 2008 -0400

    Add RDMA as a supported transport for reporting the
    mountstats statistics
    
    Signed-off-by: Tom Talpey <tmt@netapp.com>
    Acked-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit c761709ad3abb9c36a68c269f78118bf49d79639
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Mon Jun 23 12:52:33 2008 -0400

    The "mountstats" utility is a Python program that extracts and displays NFS
    client performance information from /proc/self/mountstats.
    
    Note that if mountstats is named 'ms-nfsstat' or 'ms-iostat' it offers
    slightly different functionality.  It needs two man pages and the install
    script should provide both commands by installing the script and providing the
    other command via a symlink.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 5be04020788598cb811e51c4b1342cf0796cbb65
Author: Jeff Layton <jlayton@redhat.com>
Date:   Mon Jun 23 07:21:52 2008 -0400

    The nfsstat program reads /proc/net/rpc/* files to gets info about
    calls. This info is output as unsigned numbers (at least on any
    relatively recent kernel). When nfsstat prints these numbers, they are
    printed as signed integers. When the call counters reach 2^31, things
    start being printed as negative numbers.
    
    This patch changes nfsstat to read and print all counters as unsigned
    integers. Tested by hacking up a kernel to initialize call counters to
    2^31+1.
    
    Thanks to Takafumi Miki for the initial version of this patch.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit c6acce67dce1cf89742a6bc4635c1eeda82e9591
Author: Steve Dickson <steved@redhat.com>
Date:   Fri Jun 6 17:27:23 2008 -0400

    Removed the initialization of args2 in xlog_backend. It
    caused a compilation error on x86_64 archs.
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit d03090be4f440d70328988e9f792f3bd0ebd956b
Author: Neil Brown <neilb@suse.de>
Date:   Fri Jun 6 15:17:55 2008 -0400

    nfsstat -m lists all current nfs mounts, with the mount options.
    It does this by reading /proc/mounts and looking for mounts of type
    "nfs".  It really should check for "nfs4" as well.
    
    For simplicity, just check the first 3 characters of the type.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 52dff26c60c07cf1b4fbf8fbd3a1eab7ba90405f
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Fri Jun 6 15:07:24 2008 -0400

    Fix error reporting when probe_bothports() fails while rewriting mount
    options.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit c641800eb0fcaa819199e58e5c4c8d1c2a9dab5d
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Fri Jun 6 15:06:21 2008 -0400

    Clean up: instead of passing so many arguments to all the helpers, have
    nfsmount_string build a data structure that contains all the arguments, and
    pass a pointer to that instead.
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit d7a1070383bcf40d32c7f10e535ba443209dedef
Author: Chuck Lever <chuck.lever@oracle.com>
Date:   Fri Jun 6 15:02:18 2008 -0400

    Steinar Gunderson reports:
    
    "It seems retry= is now additive with the text-based mount interface. In
    particular, "mount -o retry=0" still gives a two-minute timeout."
    
    Correct the bug and make retry= option parsing more robust.  If parsing
    the retry option fails, the option is ignored and a default timeout is
    used.
    
    Note that currently the kernel parser ignores the "retry=" option if the
    value is a number.  If the value contains other characters, the kernel will
    choke.  A subsequent patch to the kernel will allow any characters as the
    value of the retry option (excepting of course ",").
    
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 331c2ca949d5b4b4d18d0aca90afb8ae9475bcd6
Author: Neil Brown <neilb@suse.de>
Date:   Fri Jun 6 14:59:21 2008 -0400

    Make the text-based mount path check whether statd is running if the "lock"
    option is in effect.  This echoes similar logic in the legacy mount path.
    
    Signed-off-by: Neil Brown <neilb@suse.de>
    Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit fd54675db0806e81c17ee7e7eec0abfcd33f1f23
Author: Steve Dickson <steved@redhat.com>
Date:   Fri Jun 6 14:44:48 2008 -0400

    Cleaned up warnings in rmtab.c and xlog.c
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 7ef076fb98233783843d6019b2edbb48e2d18914
Author: Oren Held <oren@held.org.il>
Date:   Thu May 8 05:23:10 2008 -0400

    Fixed smail typo in exportfs man page
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 0930b25ee3a1eb28b957cdc70c9a1958812d895f
Author: NeilBrown <neilb@suse.de>
Date:   Thu May 8 05:18:25 2008 -0400

    If mount.nfs is not installed setuid, an attempt to perform a "user"
    or "users" mount will fail with a fairly obscure error message,
    typically about getting "permission denied" from the server.
    
    This patch gives a more helpful message in that case.
    
    Signed-off-by: NeilBrown <neilb@suse.de>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 25cd5f9101b8969f9e1f9d7d486f11c215d0eeb4
Author: Vince Busam <vbusam@google.com>
Date:   Wed May 7 15:24:53 2008 -0400

    Kerberos credentials may be stored in multiple places.  Make it
    possible to search several directories for valid credentials when
    making NFS requests.
    
    Original patch from Vince Busam <vbusam@google.com>
    
    Signed-off-by: Kevin Coffman <kwc@citi.umich.edu>.
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 73f9b4402ec6625618967f947c99e6e417322d36
Author: Kevin Coffman <kwc@citi.umich.edu>
Date:   Wed May 7 14:38:47 2008 -0400

    Add a new function to retrieve the current verbosity level
    so that some messages that would otherwise always print may
    be silenced.
    
    Signed-off-by: Kevin Coffman <kwc@citi.umich.edu>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 313ab396c04afe160ee6764e28b5e61ce19c46d9
Author: Kevin Coffman <kwc@citi.umich.edu>
Date:   Wed May 7 14:32:45 2008 -0400

    Add the other two DES encryption types to the default list of
    Kerberos encryption types that may be negotiated.
    
    Signed-off-by: Kevin Coffman <kwc@citi.umich.edu>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit a04f8b5a3ea94b7a9d96d339b6ccde5f2e67a2d1
Author: Olga Kornievskaia <aglo@citi.umich.edu>
Date:   Wed May 7 10:54:51 2008 -0400

    Check the info file nfs/rpc_pipefs/nfs/clnt?/info to
    see if a port number was supplied. If so, use it rather
    than the default port number.
    
    Signed-off-by: Olga Kornievskaia <aglo@citi.umich.edu>
    Signed-off-by: Kevin Coffman <kwc@citi.umich.edu>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 5fb4042ce4eb4fd5e50e3fb0f78bbd20b4d46e78
Author: Jeff Layton <jlaton@redhat.com>
Date:   Wed May 7 10:37:40 2008 -0400

    The prev_bg_host stuff made sense when NFS didn't have its own mount
    handler. Now though, each mount.nfs invocation is really a one-shot
    affair, and this check no longer works. It also leaked memory. Remove
    it.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 281ca299724f24e7b19c1eca04bba03410e2a306
Author: Jeff Layton <jlaton@redhat.com>
Date:   Wed May 7 10:35:30 2008 -0400

    The bg option is essentially ignored with nfs4 currently. nfs4mount()
    will never exit with EX_BG, so the mount will never be backgrounded.
    Fix it so that when bg is specified that we error out with EX_BG as
    soon as possible after the first failed mount attempt.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 5f7cc524008a7dc548a71f4c7b0d39759371a37a
Author: Jeff Layton <jlaton@redhat.com>
Date:   Wed May 7 10:27:53 2008 -0400

    Currently nfs4mount() sets the retry value to 10000 on both fg and bg
    mounts. It should be 2 for fg and 10000 for bg. nfsmount() sets it
    properly, but there is a potential corner case. If someone explicitly
    sets retry=10000 on a fg mount, then it will be reset to 2.
    
    Fix this by having retry default to -1 for both flavors, and then reset if
    needed after the mount options have been parsed.
    
    Signed-off-by: Jeff Layton <jlayton@redhat.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit ad1fc3feae447685a8ec8c7db0ad913fe3c4de5c
Author: Sten Spans <sten@blinkenlights.nl>
Date:   Mon May 5 14:04:58 2008 -0400

    Fixed arguments to the hosts_ctl() call in the good_client() routine
    used in the tcpwrapper support.
    
    Signe-off-by: Steve Dickson <steved@redhat.com>

commit 697e28939b7d0a3e0ffe3b6bd516213a55f5a063
Author: Jeff Layton <jlaton@redhat.com>
Date:   Mon Apr 14 09:03:13 2008 -0400

    Change how mount.nfs handles EACCES errors. Currently,
    EACCES is a non-fatal error which means the mount will be
    retied. This caused mounts to hang for 2mins when the client
    does not have permission to access the export. In a strict
    interpretation, the error that should be returned is EPERM, but
    this is not always the case. So due to the fuzzy interpretation,
    of EPERM and EACCES, EACCESS is now a fatal error
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 7d9dcf303b30aeb8b3dc06616d42a8abbdc61b27
Author: Li Yewang <lyw@cn.fujitsu.com>
Date:   Wed Apr 9 13:39:20 2008 -0400

    Correct a spelling error in a mount.nfs error message
    
    Signed-off-by: Li Yewang <lyw@cn.fujitsu.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 3899db6d602901523d6db6e2280c3bffd6c9ed63
Author: Steve Dickson <steved@redhat.com>
Date:   Tue Mar 18 09:34:58 2008 -0400

    Make sure showmount fails when rpc.mountd is not registered
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit fa29d7a9a3d8a72b79924d28813eef7e55a25bc9
Author: Steve Dickson <steved@redhat.com>
Date:   Tue Mar 18 09:33:44 2008 -0400

    Updated exportfs man to talk about /var/lib/nfs/etab
    instead of /var/lib/nfs/xtab
    
    Signed-off-by: Steve Dickson <steved@redhat.com>

commit 3c1bb23c0379864722e79d19f74c180edcf2c36e
Author: bc Wong <bcwong@cisco.com>
Date:   Tue Mar 18 09:30:44 2008 -0400

    There were 2 things wrong with auth flavour ordering:
    - Mountd used to advertise AUTH_NULL as the first flavour on
      the list, which means that it prefers AUTH_NULL to anything
      else (as per RFC 2623 section 2.7).
    - Mount.nfs used to scan the returned list in reverse order,
      and stopping at the first AUTH_NULL or AUTH_SYS encountered.
      If a server advertises (AUTH_SYS, AUTH_NULL), it will by
      default choose AUTH_NULL and have degraded access.
    
    I've fixed mount.nfs to scan from the beginning. For mountd,
    it does not advertise AUTH_NULL anymore. This is necessary
    to avoid backward compatibility issue. If AUTH_NULL appears
    in the list, either the new or the old client will choose
    that over AUTH_SYS.
    
    Tested the server/client combination against the previous
    versions, as well as Solaris and FreeBSD.
    
    Signed-off-by: bc Wong <bcwong@cisco.com>
    Signed-off-by: Steve Dickson <steved@redhat.com>



steved.

     
_______________________________________________
NFSv4 mailing list
NFSv4@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

(was: nfs-utils-1.1.3 released)

[Aníbal Monsalve Salazar]

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

On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
>issues accessing my kernel.org account so for the moment the 
>tar ball is only available on SourceForge:
>
>     http://sourceforge.net/projects/nfs
>[...] 

1.1.3 clients don't work with a 1.0.10 server anymore.

Please read the Debian bug report at http://bugs.debian.org/492970

On Fri, Aug 01, 2008 at 02:54:02PM +0200, Christian Surchi wrote:
>On Wed, Jul 30, 2008 at 12:56:12PM +0200, Rasmus Bøg Hansen wrote:
>>Package: nfs-common
>>Version: 1:1.1.3-1
>>Severity: important
>>
>>
>>Upgrading nfs-common 1:1.1.3-1 broke my NFS client.
>>
>>The NFS server is running etch and nothing was changed. After upgrading
>>the client to 1:1.1.3-1 access to my files (/home is NFS-mounted) is
>>disallowed where it should be allowed (and certainly was in 1:1.1.2-6).
>
>I confirm this one on my sid client too. No changes in nfs server 
>(etch). Downgrading nfs-common solved the problem for me too.
>
>Christian

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

_______________________________________________
NFSv4 mailing list
NFSv4@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

Re: (was: nfs-utils-1.1.3 released)

[Paul Collins]

IkouIEJydWNlIEZpZWxkcyIgPGJmaWVsZHNAZmllbGRzZXMub3JnPiB3cml0ZXM6Cgo+IE9uIEZy
aSwgQXVnIDAxLCAyMDA4IGF0IDExOjE1OjMzUE0gKzEwMDAsIEFuw61iYWwgTW9uc2FsdmUgU2Fs
YXphciB3cm90ZToKPj4gT24gTW9uLCBKdWwgMjgsIDIwMDggYXQgMDM6MTM6MTlBTSAtMDQwMCwg
U3RldmUgRGlja3NvbiB3cm90ZToKPj4gPkkganVzdCBjdXQgdGhlIDEuMS4zIG5mcy11dGlscyBy
ZWxlYXNlLiBVbmZvcnR1bmF0ZWx5IEknbSBoYXZpbmcKPj4gPmlzc3VlcyBhY2Nlc3NpbmcgbXkg
a2VybmVsLm9yZyBhY2NvdW50IHNvIGZvciB0aGUgbW9tZW50IHRoZSAKPj4gPnRhciBiYWxsIGlz
IG9ubHkgYXZhaWxhYmxlIG9uIFNvdXJjZUZvcmdlOgo+PiA+Cj4+ID4gICAgIGh0dHA6Ly9zb3Vy
Y2Vmb3JnZS5uZXQvcHJvamVjdHMvbmZzCj4+ID5bLi4uXSAKPj4gCj4+IDEuMS4zIGNsaWVudHMg
ZG9uJ3Qgd29yayB3aXRoIGEgMS4wLjEwIHNlcnZlciBhbnltb3JlLgo+Cj4gVmVyeSB3ZWlyZC0t
aXQgbWlnaHQgbWFrZSBzZW5zZSBpZiB1cGdyYWRpbmcgbmZzLXV0aWxzIGJyb2tlIHRoZSBtb3Vu
dAo+IGl0c2VsZiwgYnV0IGhlcmUgaXQgc2VlbXMgdGhlIG1vdW50IGlzIHN1Y2NlZWRpbmcgYW5k
IHN1YnNlcXVlbnQgZmlsZQo+IGFjY2VzcyAod2hpY2ggSSdkIGV4cGVjdCB0byBvbmx5IGludm9s
dmUgdGhlIGluLWtlcm5lbCBjbGllbnQgY29kZSkgaXMKPiBmYWlsaW5nLiAgTWF5YmUgdGhlcmUn
cyBzb21lIGRpZmZlcmVuY2UgaW4gdGhlIG1vdW50IG9wdGlvbnM/ICBXaGF0IGRvZXMKPiAvcHJv
Yy9zZWxmL21vdW50cyBzYXk/ICBJIGFzc3VtZSB0aGVzZSBhcmUgYWxsIHYyIG9yIHYzIG1vdW50
cz8KCkkgZGlzY292ZXJlZCB0b2RheSB0aGF0IEkgd2FzIG5vIGxvbmdlciBhYmxlIHRvIHdyaXRl
IHRvIHRoZSB2MyBtb3VudCBvbgpteSAxLjEuMiBzZXJ2ZXIuICBJIGNoZWNrZWQgL3Byb2MvbW91
bnRzIGFuZCBub3RpY2VkIHNlYz1udWxsIG9uIHRoZQptb3VudC4gIEVpdGhlciBhZGRpbmcgc2Vj
PXN5cyB0byB0aGUgY2xpZW50J3MgbW91bnQgb3B0aW9ucyBvcgpkb3duZ3JhZGluZyB0byBuZnMt
Y29tbW9uIDEuMS4yIG9uIHRoZSBjbGllbnQgZml4ZXMgdGhlIHByb2JsZW0uCgotLSAKUGF1bCBD
b2xsaW5zCldlbGxpbmd0b24sIE5ldyBaZWFsYW5kCgpEYWcgdmlqYW5kZWxpamsgbHVjaHRzY2hp
cCBkZSBodWlzbWVlc3RlciBpcyBkb29kCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fCk5GU3Y0IG1haWxpbmcgbGlzdApORlN2NEBsaW51eC1uZnMub3JnCmh0
dHA6Ly9saW51eC1uZnMub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9uZnN2NA==

Re: (was: nfs-utils-1.1.3 released)

[J. Bruce Fields]

On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>=20
> > On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Sala=
zar wrote:
> >> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
> >> >I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
> >> >issues accessing my kernel.org account so for the moment the=20
> >> >tar ball is only available on SourceForge:
> >> >
> >> >     http://sourceforge.net/projects/nfs
> >> >[...]=20
> >>=20
> >> 1.1.3 clients don't work with a 1.0.10 server anymore.
> >
> > Very weird--it might make sense if upgrading nfs-utils broke the mo=
unt
> > itself, but here it seems the mount is succeeding and subsequent fi=
le
> > access (which I'd expect to only involve the in-kernel client code)=
 is
> > failing.  Maybe there's some difference in the mount options?  What=
 does
> > /proc/self/mounts say?  I assume these are all v2 or v3 mounts?
>=20
> I discovered today that I was no longer able to write to the v3 mount=
 on
> my 1.1.2 server.  I checked /proc/mounts and noticed sec=3Dnull on th=
e
> mount.  Either adding sec=3Dsys to the client's mount options or
> downgrading to nfs-common 1.1.2 on the client fixes the problem.

That would do it!

So it sounds like there's a bug that causes mount.nfs to get the defaul=
t
mount options wrong?

--b.

Re: (was: nfs-utils-1.1.3 released)

[Chuck Lever]

On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>> "J. Bruce Fields" <bfields@fieldses.org> writes:
>>
>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve Salazar  =

>>> wrote:
>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
>>>>> issues accessing my kernel.org account so for the moment the
>>>>> tar ball is only available on SourceForge:
>>>>>
>>>>>    http://sourceforge.net/projects/nfs
>>>>> [...]
>>>>
>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>
>>> Very weird--it might make sense if upgrading nfs-utils broke the  =

>>> mount
>>> itself, but here it seems the mount is succeeding and subsequent  =

>>> file
>>> access (which I'd expect to only involve the in-kernel client  =

>>> code) is
>>> failing.  Maybe there's some difference in the mount options?   =

>>> What does
>>> /proc/self/mounts say?  I assume these are all v2 or v3 mounts?
>>
>> I discovered today that I was no longer able to write to the v3  =

>> mount on
>> my 1.1.2 server.  I checked /proc/mounts and noticed sec=3Dnull on the
>> mount.  Either adding sec=3Dsys to the client's mount options or
>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>
> That would do it!
>
> So it sounds like there's a bug that causes mount.nfs to get the  =

> default
> mount options wrong?

I'm not sure I'm following this.  I can't think of a user-space  =

mount.nfs change in 1.1.3 that would affect the sec=3D option.

Paul, which kernel are you running on your clients?

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re: (was: nfs-utils-1.1.3 released)

[Paul Collins]

Chuck Lever <chuck.lever@oracle.com> writes:

> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>> "J. Bruce Fields" <bfields@fieldses.org> writes:
>>>
>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Sal=
azar
>>>> wrote:
>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>> tar ball is only available on SourceForge:
>>>>>>
>>>>>>    http://sourceforge.net/projects/nfs
>>>>>> [...]
>>>>>
>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>
>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>> mount
>>>> itself, but here it seems the mount is succeeding and subsequent
>>>> file
>>>> access (which I'd expect to only involve the in-kernel client
>>>> code) is
>>>> failing.  Maybe there's some difference in the mount options?
>>>> What does
>>>> /proc/self/mounts say?  I assume these are all v2 or v3 mounts?
>>>
>>> I discovered today that I was no longer able to write to the v3
>>> mount on
>>> my 1.1.2 server.  I checked /proc/mounts and noticed sec=3Dnull on =
the
>>> mount.  Either adding sec=3Dsys to the client's mount options or
>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>
>> That would do it!
>>
>> So it sounds like there's a bug that causes mount.nfs to get the
>> default
>> mount options wrong?
>
> I'm not sure I'm following this.  I can't think of a user-space
> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>
> Paul, which kernel are you running on your clients?

Either 2.6.26 or 2.6.27-rc1+.  I'll double-check.

Whichever one it was, the problem was present with 1.1.3 installed, and
not present with 1.1.2 installed.

--=20
Paul Collins
Wellington, New Zealand

Dag vijandelijk luchtschip de huismeester is dood

Re: (was: nfs-utils-1.1.3 released)

[Chuck Lever]

On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
> Chuck Lever <chuck.lever@oracle.com> writes:
>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>> "J. Bruce Fields" <bfields@fieldses.org> writes:
>>>>
>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve Salaz=
ar
>>>>> wrote:
>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm havin=
g
>>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>>> tar ball is only available on SourceForge:
>>>>>>>
>>>>>>>   http://sourceforge.net/projects/nfs
>>>>>>> [...]
>>>>>>
>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>
>>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>>> mount
>>>>> itself, but here it seems the mount is succeeding and subsequent
>>>>> file
>>>>> access (which I'd expect to only involve the in-kernel client
>>>>> code) is
>>>>> failing.  Maybe there's some difference in the mount options?
>>>>> What does
>>>>> /proc/self/mounts say?  I assume these are all v2 or v3 mounts?
>>>>
>>>> I discovered today that I was no longer able to write to the v3
>>>> mount on
>>>> my 1.1.2 server.  I checked /proc/mounts and noticed sec=3Dnull on=
 =20
>>>> the
>>>> mount.  Either adding sec=3Dsys to the client's mount options or
>>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>>
>>> That would do it!
>>>
>>> So it sounds like there's a bug that causes mount.nfs to get the
>>> default
>>> mount options wrong?
>>
>> I'm not sure I'm following this.  I can't think of a user-space
>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>
>> Paul, which kernel are you running on your clients?
>
> Either 2.6.26 or 2.6.27-rc1+.  I'll double-check.

It would be interesting if you could try both.  I suspect 2.6.26 =20
doesn't exhibit this problem, as 27-rc1 has changes in the NFS mount =20
parser that affect "sec=3D".

Also, enabling NFS mount debugging messages when performing the mount =20
that eventually doesn't work would be enlightening (for me).  Either:

   sudo sysctl -w sunrpc.nfs_debug=3D2048

or if you have the latest rpcdebug installed:

   sudo rpcdebug -m nfs -s mount

Then perform the mount.  Take a look in /var/log/messages for the =20
debugging messages.

And, please send the full command line of the failing mount request.

> Whichever one it was, the problem was present with 1.1.3 installed, =20
> and
> not present with 1.1.2 installed.

Gotcha.

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Bug#492970: (was: nfs-utils-1.1.3 released)

[Rasmus Bøg Hansen]

Chuck Lever <chuck.lever@oracle.com> writes:

> On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
>> Chuck Lever <chuck.lever@oracle.com> writes:
>>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>>> "J. Bruce Fields" <bfields@fieldses.org> writes:
>>>>>
>>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=C3=ADbal Monsalve Salaz=
ar
>>>>>> wrote:
>>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm having
>>>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>>>> tar ball is only available on SourceForge:
>>>>>>>>
>>>>>>>>   http://sourceforge.net/projects/nfs
>>>>>>>> [...]
>>>>>>>
>>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>>
>>>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>>>> mount
>>>>>> itself, but here it seems the mount is succeeding and subsequent
>>>>>> file
>>>>>> access (which I'd expect to only involve the in-kernel client
>>>>>> code) is
>>>>>> failing.  Maybe there's some difference in the mount options?
>>>>>> What does
>>>>>> /proc/self/mounts say?  I assume these are all v2 or v3 mounts?
>>>>>
>>>>> I discovered today that I was no longer able to write to the v3
>>>>> mount on
>>>>> my 1.1.2 server.  I checked /proc/mounts and noticed sec=3Dnull on
>>>>> the
>>>>> mount.  Either adding sec=3Dsys to the client's mount options or
>>>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>>>
>>>> That would do it!
>>>>
>>>> So it sounds like there's a bug that causes mount.nfs to get the
>>>> default
>>>> mount options wrong?
>>>
>>> I'm not sure I'm following this.  I can't think of a user-space
>>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>>
>>> Paul, which kernel are you running on your clients?
>>
>> Either 2.6.26 or 2.6.27-rc1+.  I'll double-check.
>
> It would be interesting if you could try both.  I suspect 2.6.26
> doesn't exhibit this problem, as 27-rc1 has changes in the NFS mount
> parser that affect "sec=3D".

I had the problem with 2.6.26. I didn't try 2.6.27-rc1 on that
machine.

> Also, enabling NFS mount debugging messages when performing the mount
> that eventually doesn't work would be enlightening (for me).  Either:

I won't be around that machine for a week or so.

>> Whichever one it was, the problem was present with 1.1.3 installed,
>> and
>> not present with 1.1.2 installed.

Same here.

Regards
/Rasmus

--=20
Rasmus B=C3=B8g Hansen
MSC Aps
B=C3=B8gesvinget 8
2740 Skovlunde
44 53 93 66

Re: (was: nfs-utils-1.1.3 released)

[Chuck Lever]

On Aug 5, 2008, at 3:28 PM, Rasmus B=F8g Hansen wrote:
> Chuck Lever <chuck.lever@oracle.com> writes:
>> On Aug 4, 2008, at 4:55 PM, Paul Collins wrote:
>>> Chuck Lever <chuck.lever@oracle.com> writes:
>>>> On Aug 3, 2008, at 11:10 AM, J. Bruce Fields wrote:
>>>>> On Mon, Aug 04, 2008 at 12:37:19AM +1200, Paul Collins wrote:
>>>>>> "J. Bruce Fields" <bfields@fieldses.org> writes:
>>>>>>
>>>>>>> On Fri, Aug 01, 2008 at 11:15:33PM +1000, An=EDbal Monsalve  =

>>>>>>> Salazar
>>>>>>> wrote:
>>>>>>>> On Mon, Jul 28, 2008 at 03:13:19AM -0400, Steve Dickson wrote:
>>>>>>>>> I just cut the 1.1.3 nfs-utils release. Unfortunately I'm  =

>>>>>>>>> having
>>>>>>>>> issues accessing my kernel.org account so for the moment the
>>>>>>>>> tar ball is only available on SourceForge:
>>>>>>>>>
>>>>>>>>>  http://sourceforge.net/projects/nfs
>>>>>>>>> [...]
>>>>>>>>
>>>>>>>> 1.1.3 clients don't work with a 1.0.10 server anymore.
>>>>>>>
>>>>>>> Very weird--it might make sense if upgrading nfs-utils broke the
>>>>>>> mount
>>>>>>> itself, but here it seems the mount is succeeding and subsequent
>>>>>>> file
>>>>>>> access (which I'd expect to only involve the in-kernel client
>>>>>>> code) is
>>>>>>> failing.  Maybe there's some difference in the mount options?
>>>>>>> What does
>>>>>>> /proc/self/mounts say?  I assume these are all v2 or v3 mounts?
>>>>>>
>>>>>> I discovered today that I was no longer able to write to the v3
>>>>>> mount on
>>>>>> my 1.1.2 server.  I checked /proc/mounts and noticed sec=3Dnull on
>>>>>> the
>>>>>> mount.  Either adding sec=3Dsys to the client's mount options or
>>>>>> downgrading to nfs-common 1.1.2 on the client fixes the problem.
>>>>>
>>>>> That would do it!
>>>>>
>>>>> So it sounds like there's a bug that causes mount.nfs to get the
>>>>> default
>>>>> mount options wrong?
>>>>
>>>> I'm not sure I'm following this.  I can't think of a user-space
>>>> mount.nfs change in 1.1.3 that would affect the sec=3D option.
>>>>
>>>> Paul, which kernel are you running on your clients?
>>>
>>> Either 2.6.26 or 2.6.27-rc1+.  I'll double-check.
>>
>> It would be interesting if you could try both.  I suspect 2.6.26
>> doesn't exhibit this problem, as 27-rc1 has changes in the NFS mount
>> parser that affect "sec=3D".
>
> I had the problem with 2.6.26. I didn't try 2.6.27-rc1 on that
> machine.
>
>> Also, enabling NFS mount debugging messages when performing the mount
>> that eventually doesn't work would be enlightening (for me).  Either:
>
> I won't be around that machine for a week or so.
>
>>> Whichever one it was, the problem was present with 1.1.3 installed,
>>> and
>>> not present with 1.1.2 installed.
>
> Same here.

Thanks for the report.

In addition to the debugging mentioned above, anyone encountering this  =

regression can also try a git bisect on nfs-utils (between 1.1.2 and  =

1.1.3).

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

Re:

[Sergey Bolshakov]

>>>>> "Chuck" == Chuck Lever <chuck.lever@oracle.com> writes:
[skipped]

 > In addition to the debugging mentioned above, anyone encountering this  
 > regression can also try a git bisect on nfs-utils (between 1.1.2 and  
 > 1.1.3).

I've seen same thing with degraded sec=none having SUSE 9SP3
nfs-utils-1.0.6-103.23 on server side and 1.1.2-3899db6d
on client side, so 3c1bb23c seems causing problems.

-- 

(unknown)

[Linus Torvalds]

Trond?

See 'http://lkml.org/lkml/2008/7/17/154'? It's been 10+ days, it's 
apparently still there.

		Linus

RE:

[Trond Myklebust]

On Sun, 2008-07-27 at 10:40 -0700, Linus Torvalds wrote:
> Trond?
> 
> See 'http://lkml.org/lkml/2008/7/17/154'? It's been 10+ days, it's 
> apparently still there.
> 
> 		Linus

Sure thing...

Please pull from the "hotfixes" branch of the repository at

   git pull git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git hotfixes

This will update the following files through the appended changesets.

  Cheers,
    Trond

----
 fs/nfs/super.c  |    6 +++---
 fs/nfs/unlink.c |    3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

commit 744d18dbfae07482ea461701b0aaec3a75ec9224
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date:   Sun Jul 27 18:03:19 2008 -0400

    NFS: Ensure we call nfs_sb_deactive() after releasing the directory inode
    
    In order to avoid the "Busy inodes after unmount" error message, we need to
    ensure that nfs_async_unlink_release() releases the super block after the
    call to nfs_free_unlinkdata().
    
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

commit 31c9446993f412ecb7875e30bba4bc7f216ae016
Author: Marc Zyngier <maz@misterjones.org>
Date:   Thu Jul 17 13:21:55 2008 +0200

    nfs_remount oops when rebooting + possible fix
    
    Jeff, Trond,
    
    The commit
    
    48b605f83c920d8daa50e43fc2c7f718e04c7bfa (NFS: implement option checking
    when remounting NFS filesystems (resend))
    
    generate an Oops on my platform when rebooting while its root FS on
    an NFS share (NFSv3, TCP) :
    
    Unmounting local filesystems...done.
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
    pgd = c3d00000
    [00000000] *pgd=a3d72031, *pte=00000000, *ppte=00000000
    Internal error: Oops: 17 [#1]
    Modules linked in: cpufreq_powersave cpufreq_ondemand cpufreq_userspace cpufreq_conservative ext3 jbd sd_mod pata_pcmcia libata scsi_mod pcmcia loop firmware_class pxafb cfbcopyarea cfbimgblt cfbfillrect pxa2xx_cs pxa2xx_core pcmcia_core snd_pxa2xx_ac97 snd_ac97_codec ac97_bus snd_pxa2xx_pcm snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd isp116x_hcd soundcore rtc_sa1100 snd_page_alloc pxa25x_udc usbcore rtc_ds1307 rtc_core
    CPU: 0    Not tainted  (2.6.26-03414-g33af79d-dirty #15)
    PC is at nfs_remount+0x40/0x264
    LR is at do_remount_sb+0x158/0x194
    pc : [<c00bbf54>]    lr : [<c0076c40>]    psr: 60000013
    sp : c2dd1e70  ip : c2dd1e98  fp : c2dd1e94
    r10: 00000040  r9 : c3d17000  r8 : c3c3fc40
    r7 : 00000000  r6 : 00000000  r5 : c3d2b200  r4 : 00000000
    r3 : 00000003  r2 : 00000000  r1 : c2dd1e9c  r0 : c3c3fc00
    Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
    Control: 0000397f  Table: a3d00000  DAC: 00000015
    Process mount (pid: 1462, stack limit = 0xc2dd0270)
    Stack: (0xc2dd1e70 to 0xc2dd2000)
    1e60:                                     00000000 c3c3fc00 00000000 00000000
    1e80: c3c3fc40 c3d17000 c2dd1ebc c2dd1e98 c0076c40 c00bbf20 c01c61e4 00000001
    1ea0: c2dd1ebc 00000001 c3c3fc00 c2dd1ef0 c2dd1ee4 c2dd1ec0 c008c6d8 c0076af4
    1ec0: 00000021 00000040 c2dd1ef0 c3d77000 c3eaa000 00000000 c2dd1f6c c2dd1ee8
    1ee0: c008d1bc c008c5f8 00000000 c2dd0000 c3c0c320 c3805b38 c002064c 0001f820
    1f00: 0001f810 00000001 00000001 00000000 c2dd0000 00000000 c2dd1f34 c2dd1f28
    1f20: c005ead8 c005e6f8 c2dd1f44 c2dd1f38 c005eaf8 c005ead0 c2dd1f6c c2dd1f48
    1f40: c008ae3c 00000000 c3d77000 0001f810 c0ed0021 c0020ca8 c2dd0000 00000000
    1f60: c2dd1fa4 c2dd1f70 c008d2d4 c008d0bc 00000000 0001f810 c2dd1f9c c3eaa000
    1f80: c3d17000 00000000 00000000 be8b6aa8 be8b6ad0 00000015 00000000 c2dd1fa8
    1fa0: c0020b00 c008d254 00000000 be8b6aa8 0001f810 0001f820 0001f830 c0ed0021
    1fc0: 00000000 be8b6aa8 be8b6ad0 00000015 00000000 be8b6ad0 0001f810 be8b6aa8
    1fe0: 0001f810 be8b6964 0000aab8 40125124 60000010 0001f810 00000000 00000000
    Backtrace:
    [<c00bbf14>] (nfs_remount+0x0/0x264) from [<c0076c40>] (do_remount_sb+0x158/0x194)
      r9:c3d17000 r8:c3c3fc40 r7:00000000 r6:00000000 r5:c3c3fc00
    r4:00000000
    [<c0076ae8>] (do_remount_sb+0x0/0x194) from [<c008c6d8>] (do_remount+0xec/0x118)
      r6:c2dd1ef0 r5:c3c3fc00 r4:00000001
    [<c008c5ec>] (do_remount+0x0/0x118) from [<c008d1bc>] (do_mount+0x10c/0x198)
    [<c008d0b0>] (do_mount+0x0/0x198) from [<c008d2d4>] (sys_mount+0x8c/0xd4)
    [<c008d248>] (sys_mount+0x0/0xd4) from [<c0020b00>] (ret_fast_syscall+0x0/0x2c)
      r7:00000015 r6:be8b6ad0 r5:be8b6aa8 r4:00000000
    Code: 0a000086 ea000006 e3530003 8a000004 (e5923000)
    ---[ end trace 55e1b689cf8c8a6a ]---
    ------------[ cut here ]------------
    WARNING: at kernel/exit.c:966 do_exit+0x3c/0x628()
    Modules linked in: cpufreq_powersave cpufreq_ondemand cpufreq_userspace cpufreq_conservative ext3 jbd sd_mod pata_pcmcia libata scsi_mod pcmcia loop firmware_class pxafb cfbcopyarea cfbimgblt cfbfillrect pxa2xx_cs pxa2xx_core pcmcia_core snd_pxa2xx_ac97 snd_ac97_codec ac97_bus snd_pxa2xx_pcm snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd isp116x_hcd soundcore rtc_sa1100 snd_page_alloc pxa25x_udc usbcore rtc_ds1307 rtc_core
    [<c0025168>] (dump_stack+0x0/0x14) from [<c0032154>] (warn_on_slowpath+0x4c/0x68)
    [<c0032108>] (warn_on_slowpath+0x0/0x68) from [<c003531c>] (do_exit+0x3c/0x628)
      r6:0000000b r5:c3c3dc80 r4:c2dd0000
    [<c00352e0>] (do_exit+0x0/0x628) from [<c0025004>] (die+0x2b0/0x30c)
    [<c0024d54>] (die+0x0/0x30c) from [<c00270bc>] (__do_kernel_fault+0x6c/0x80)
    [<c0027050>] (__do_kernel_fault+0x0/0x80) from [<c00272e0>] (do_page_fault+0x210/0x230)
      r7:c3fa7118 r6:c3c3dc80 r5:c3d166a8 r4:00010000
    [<c00270d0>] (do_page_fault+0x0/0x230) from [<c00201ec>] (do_DataAbort+0x3c/0xa0)
    [<c00201b0>] (do_DataAbort+0x0/0xa0) from [<c002064c>] (__dabt_svc+0x4c/0x60)
    Exception stack(0xc2dd1e28 to 0xc2dd1e70)
    1e20:                   c3c3fc00 c2dd1e9c 00000000 00000003 00000000 c3d2b200
    1e40: 00000000 00000000 c3c3fc40 c3d17000 00000040 c2dd1e94 c2dd1e98 c2dd1e70
    1e60: c0076c40 c00bbf54 60000013 ffffffff
      r8:c3c3fc40 r7:00000000 r6:00000000 r5:c2dd1e5c r4:ffffffff
    [<c00bbf14>] (nfs_remount+0x0/0x264) from [<c0076c40>] (do_remount_sb+0x158/0x194)
      r9:c3d17000 r8:c3c3fc40 r7:00000000 r6:00000000 r5:c3c3fc00
    r4:00000000
    [<c0076ae8>] (do_remount_sb+0x0/0x194) from [<c008c6d8>] (do_remount+0xec/0x118)
      r6:c2dd1ef0 r5:c3c3fc00 r4:00000001
    [<c008c5ec>] (do_remount+0x0/0x118) from [<c008d1bc>] (do_mount+0x10c/0x198)
    [<c008d0b0>] (do_mount+0x0/0x198) from [<c008d2d4>] (sys_mount+0x8c/0xd4)
    [<c008d248>] (sys_mount+0x0/0xd4) from [<c0020b00>] (ret_fast_syscall+0x0/0x2c)
      r7:00000015 r6:be8b6ad0 r5:be8b6aa8 r4:00000000
    ---[ end trace 55e1b689cf8c8a6a ]---
    /etc/rc6.d/S60umountroot: line 17:  1462 Segmentation fault      mount $MOUNT_FORCE_OPT -n -o remount,ro -t dummytype dummydev / 2> /dev/null
    
    The new super.c:nfs_remount function doesn't check the validity of the
    options/options4 pointers. Unfortunately, this seems to happend.
    The obvious patch seems to check the pointers, and not to do anything if
    the happend to be NULL.
    
    Tested on an XScale PXA255 system, latest git.
    
    Regards,
    
    	M.
    
    Signed-off-by: Marc Zyngier <marc.zyngier@altran.com>
    Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>

diff --git a/fs/nfs/super.c b/fs/nfs/super.c
index 1b94e36..9abcd2b 100644
--- a/fs/nfs/super.c
+++ b/fs/nfs/super.c
@@ -1718,9 +1718,9 @@ nfs_remount(struct super_block *sb, int *flags, char *raw_data)
 	 * ones were explicitly specified. Fall back to legacy behavior and
 	 * just return success.
 	 */
-	if ((nfsvers == 4 && options4->version == 1) ||
-	    (nfsvers <= 3 && options->version >= 1 &&
-	     options->version <= 6))
+	if ((nfsvers == 4 && (!options4 || options4->version == 1)) ||
+	    (nfsvers <= 3 && (!options || (options->version >= 1 &&
+					   options->version <= 6))))
 		return 0;
 
 	data = kzalloc(sizeof(*data), GFP_KERNEL);
diff --git a/fs/nfs/unlink.c b/fs/nfs/unlink.c
index 3adf8b2..f089e58 100644
--- a/fs/nfs/unlink.c
+++ b/fs/nfs/unlink.c
@@ -95,10 +95,11 @@ static void nfs_async_unlink_done(struct rpc_task *task, void *calldata)
 static void nfs_async_unlink_release(void *calldata)
 {
 	struct nfs_unlinkdata	*data = calldata;
+	struct super_block *sb = data->dir->i_sb;
 
 	nfs_dec_sillycount(data->dir);
-	nfs_sb_deactive(NFS_SERVER(data->dir));
 	nfs_free_unlinkdata(data);
+	nfs_sb_deactive(NFS_SB(sb));
 }
 
 static const struct rpc_call_ops nfs_unlink_ops = {


-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re:

[Emily]

Email Marketing is one of the most effective and inexpensive ways to 
promote your products and services.

We offer a complete Email Marketing solution with quality service and the 
lowest prices. The result is that you will enjoy more success.

1. Targeted Email Addresses 

We can supply targeted email addresses according to your requirements,
which are compiled only on your order, such as region / country / field / 
occupation / Domain Name etc. We will customize your customer email
addresses.

* We have millions of email addresses in a wide variety of categories.

2. Targeted Mailing  

If you are worried about any complications or consequences with sending 
out targeted emails, or want to avoid the work of sending out targeted 
emails. We will do it for you! We will send your email message to your 
targeted customers.

* We can Bullet Proof your Web Site.

We also offer a wide variety of email marketing software. For more details, 
you can refer to our web site: http://www.biz-aiding.com

Our services will help you get more business opportunities.


Regards!

Barbara Clayton
Marketing Services
www.biz-aiding.com

Targeted Marketing, at Great Fee.

***************************************************************************
Receiving this email because you registered to receive special 
offers from one of our partners. If you would prefer not to receive
future email, Click here: www.unsubscribe-mail.com
***************************************************************************


-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com

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