What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree... - Kernel

This is a discussion on What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree... - Kernel ; Aside from the usual updates from Chuck for NFS-over-IPv6 (still incomplete) and a number of bugfixes for the text-based mount code, the main news in the NFS tree is the merging of support for the NFS/RDMA client code from Tom ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

  1. What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    Aside from the usual updates from Chuck for NFS-over-IPv6 (still
    incomplete) and a number of bugfixes for the text-based mount code, the
    main news in the NFS tree is the merging of support for the NFS/RDMA
    client code from Tom Talpey and the NetApp New England (NANE) team.

    We also have the 64-bit inode support from RedHat/Peter Staubach.

    There is also the addition of a nfs_vm_page_mkwrite() method in order to
    clean up the mmap() write code.
    Finally, I've been working on a number of updates for the attribute
    revalidation, having pulled apart most of the dentry and attribute
    revalidation into separate variables. A number of fixes that address
    existing bugs fell out of that review, which should hopefully result in
    more efficient dcache behaviour...

    The NFS client git tree can be found at

    git://git.linux-nfs.org/pub/linux/nfs-2.6.git

    or on gitweb at

    http://linux-nfs.org/cgi-bin/gitweb.....git;a=summary

    Finally, a full set of patches may be found on

    http://client.linux-nfs.org/Linux-2.6.x/2.6.23-rc9/

    Cheers
    Trond

    -------------------

    Adrian Bunk (1):
    [2.6 patch] net/sunrpc/rpcb_clnt.c: make struct rpcb_program static

    Christoph Hellwig (1):
    [NFS] [PATCH] nfs: tiny makefile cleanup

    Chuck Lever (41):
    SUNRPC: Fix a signed v. unsigned comparison in rpcbind's XDR routines
    SUNRPC: Fix a signed v. unsigned comparison in net/sunrpc/xprtsock.c
    SUNRPC: Use standard macros for printing IP addresses
    SUNRPC: Free address buffers in a loop
    SUNRPC: Add hex-formatted address support to rpc_peeraddr2str()
    SUNRPC: Rename xs_format_peer_addresses
    SUNRPC: add a function to format IPv6 addresses
    SUNRPC: add support for IPv6 to the kernel's rpcbind client
    SUNRPC: Introduce support for setting the port number in IPv6 addresses
    SUNRPC: Rename xs_bind() to prepare for IPv6-specific bind method
    SUNRPC: create an IPv6-savvy mechanism for binding to a reserved port
    SUNRPC: Refactor a part of socket connect logic into a helper function
    SUNRPC: Rename IPv4 connect workers
    SUNRPC: create connect workers for IPv6
    SUNRPC: Add IPv6 address support to net/sunrpc/xprtsock.c
    SUNRPC: Add a helper for extracting the address using the correct type
    SUNRPC: Split xs_reclassify_socket into an IPv4 and IPv6 version
    SUNRPC: Add support for formatted universal addresses
    SUNRPC: Fix generation of universal addresses for
    SUNRPC: Only one dprintk is needed during client creation
    SUNRPC: fix a signed v. unsigned comparison nit in rpc_bind_new_program
    SUNRPC: Use correct argument type in memcpy()
    SUNRPC: Make sure server name is reasonable before trying to print it
    SUNRPC: Clean up in rpc_show_tasks
    SUNRPC: Make rpcb_decode_getaddr more picky about universal addresses
    SUNRPC: Retry bad rpcbind replies
    SUNRPC: Add a new error code for retry waiting for another binder
    SUNRPC: Split another new rpcbind retry error code from EACCES
    SUNRPC: RPC bind failures should be permanent for NULL requests
    NFS: Kernel mount client should use async bind
    NFS: Add new 'mountaddr=' mount option
    NFS: Convert printk's to dprintk's in fs/nfs/nfs?xdr.c
    LOCKD: Convert printk's to dprintk's in lockd XDR routines
    NFSD: Convert printk's to dprintk's in NFSD's nfs4xdr
    NFS: Verify server address before invoking in-kernel mount client
    NFS: Show "nointr" mount option
    SUNRPC: Fix bytes-per-op accounting for RPC over UDP
    NFS: Don't call nfs_renew_times() in nfs_dentry_iput()
    NFS: Eliminate nfs_renew_times()
    NFS: Eliminate nfs_refresh_verifier()
    SUNRPC: Use correct type in buffer length calculations

    Fabio Olive Leite (1):
    Re: [NFS] [PATCH] Attribute timeout handling and wrapping u32 jiffies

    J. Bruce Fields (2):
    nfs: add server port to rpc_pipe info file
    SUNRPC: Fix default hostname created in rpc_create()

    James Lentini (1):
    [NFS] [PATCH] NFS: initialize default port in kernel mount client

    Jeff Layton (1):
    [NFS] [PATCH] NFS: show addr=ipaddr in /proc/mounts rather than

    Jesper Juhl (1):
    [23/37] Clean up duplicate includes in

    Peter Staubach (1):
    64 bit ino support for NFS client

    Trond Myklebust (56):
    NFS: Add the helper nfs_vm_page_mkwrite
    NFS: Clean up write code...
    NFS: Clean up nfs_writepages()
    VFS: Remove writeback_control->fs_private
    NFS: Clean up NFS writeback flush code
    NFS: Writeback optimisation
    NFS: Fall back to synchronous writes when a background write errors...
    SUNRPC: Convert rpc_pipefs to use the generic filesystem notification hooks
    NFSv4: Fix a bug in nfs4_validate_mount_data()
    NFS: Add a helper to extract the nfs_open_context from a struct file
    NFS: Replace file->private_data with calls to nfs_file_open_context()
    NFSv4: Simplify _nfs4_do_access()
    NFSv4: Make NFSv4 ACCESS calls return attributes too...
    NFS: Fix over-conservative attribute invalidation in nfs_update_inode()
    NFS: nfs_post_op_update_inode() should call nfs_refresh_inode()
    NFS: fix nfs_verify_change_attribute
    NFS: Fix dcache revalidation bugs
    NFS: nfs_wcc_update_inode: directory caches are always invalidated
    NFS: Don't force a dcache revalidation if nfs_wcc_update_inode succeeds
    NFSv4: Don't use ctime/mtime for determining when to invalidate the caches
    NFS: Don't use readdirplus data if the page cache is invalid
    NFS: Fix atime revalidation in readdir()
    NFS: Fix atime revalidation in read()
    NFS: Fix the ESTALE "revalidation" in _nfs_revalidate_inode()
    NFS: Remove bogus check of cache_change_attribute in nfs_update_inode
    NFS: Fake up 'wcc' attributes to prevent cache invalidation after write
    NFS: Fix the sign of the return value of nfs_save_change_attribute()
    NFS: Fix nfs_verify_change_attribute()
    NFS: Ensure nfs_instantiate() invalidates the parent dir on error
    NFS: nfs_instantiate() should set the dentry verifier
    NFS: Don't hash the negative dentry when optimising for an O_EXCL open
    NFS: Fix a bug in nfs_open_revalidate()
    NFS: Don't set cache_change_attribute in nfs_revalidate_mapping
    NFS: Don't revalidate dentries on directory size or ctime changes
    NFS: nfs_post_op_update_inode don't update cache_change_attribute
    NFS: nfs_mark_for_revalidate don't update cache_change_attribute
    NFS: don't cache the verifer across ->lookup() calls
    NFS: Remove bogus nfs_mark_for_revalidate() in nfs_lookup
    NFS: NFS_CACHEINV() should not test for nfs_caches_unstable()
    NFS: Remove NFS_I(inode)->data_updates
    NFS: Remove nfs_begin_data_update/nfs_end_data_update
    NFS: Reset nfsi->last_updated only if the attribute changed
    NFS: Optimise nfs_lookup_revalidate()
    NFSv4: Don't revalidate the directory in nfs_atomic_lookup()
    NFSv4: Use NFSv2/v3 rules for negative dentries in nfs_open_revalidate
    NFSv4: Fix nfs_atomic_open() to set the verifier on negative dentries too
    NFSv3: Always use directory post-op attributes in nfs3_proc_lookup
    NFS: Remove the redundant nfs_reval_fsid()
    NFS: Don't zap the readdir caches upon error
    NFS: Be strict about dentry revalidation when doing exclusive create
    NFS: Ensure that nfs_link() returns a hashed dentry
    NFS: Simplify filehandle revalidation
    NFS: Get rid of some obsolete macros
    SUNRPC: Fix buggy UDP transmission
    SUNRPC: Don't call xprt_release() if call_allocate fails
    SUNRPC: Don't call xprt_release in call refresh

    \"Talpey, Thomas\ (20):
    SUNRPC: move per-transport rpcbind netid's
    SUNRPC: export per-transport rpcbind netid's
    NFS: move nfs_parsed_mount_data structure definition
    NFS: use in-kernel mount argument structure for nfsv[23] mounts
    NFS: use in-kernel mount argument structure for nfsv4 mounts
    SUNRPC: mark bulk read/write data in xdrbuf
    SUNRPC: add EXPORT_SYMBOL_GPL for generic transport functions
    SUNRPC: Provide a new API for registering transport implementations
    SUNRPC: Finish API to load RPC transport implementations dynamically
    SUNRPC: rename the rpc_xprtsock_create structure
    SUNRPC: rearrange RPC sockets definitions
    NFS/SUNRPC: support transport protocol naming
    NFS/SUNRPC: use transport protocol naming
    NFS - print accurate transport protocol
    RPCRDMA: Kconfig and header file with rpcrdma protocol definitions
    NFS: support RDMA mounts
    RPCRDMA: rpc rdma transport switch
    RPCRDMA: rpc rdma protocol implementation
    RPCRDMA: rpc rdma verbs interface implementation
    SUNRPC: Add RDMA dependency to SUNRPC_XPRT_RDMA



    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    Trond Myklebust wrote:
    > Aside from the usual updates from Chuck for NFS-over-IPv6 (still
    > incomplete) and a number of bugfixes for the text-based mount code, the
    > main news in the NFS tree is the merging of support for the NFS/RDMA
    > client code from Tom Talpey and the NetApp New England (NANE) team.
    >
    > We also have the 64-bit inode support from RedHat/Peter Staubach.


    The marketroids compel me to say: It is Red Hat, not RedHat

    Jeff, looking forward to NFSv4 over IPv6


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Wed, 03 Oct 2007 19:41:16 -0400
    Trond Myklebust wrote:

    >
    > We also have the 64-bit inode support from RedHat/Peter Staubach.
    >


    As has been pointed[1] out[2], this will cause regressions for non-LFS
    applications (of which there are still lots and lots). This change
    should be in feature-removal (the "feature" being removed is legacy
    support for non-LFS applications using NFS servers that make full use
    of the protocol) and preferably accompanied with appropriate user space
    changes (e.g. compatibility option in glibc).

    [1] https://bugzilla.redhat.com/show_bug.cgi?id=241348
    [2] http://marc.info/?l=linux-nfs&m=118701088726477&w=2

    Rgds
    --
    -- Pierre Ossman

    Linux kernel, MMC maintainer http://www.kernel.org
    PulseAudio, core developer http://pulseaudio.org
    rdesktop, core developer http://www.rdesktop.org
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote:
    > On Wed, 03 Oct 2007 19:41:16 -0400
    > Trond Myklebust wrote:
    >
    > >
    > > We also have the 64-bit inode support from RedHat/Peter Staubach.
    > >

    >
    > As has been pointed[1] out[2], this will cause regressions for non-LFS
    > applications (of which there are still lots and lots). This change
    > should be in feature-removal (the "feature" being removed is legacy
    > support for non-LFS applications using NFS servers that make full use
    > of the protocol) and preferably accompanied with appropriate user space
    > changes (e.g. compatibility option in glibc).
    >
    > [1] https://bugzilla.redhat.com/show_bug.cgi?id=241348
    > [2] http://marc.info/?l=linux-nfs&m=118701088726477&w=2
    >
    > Rgds


    How about a boot/module parameter to turn it on or off?

    I don't see any point in having a sysctl for something like this: either
    you have legacy applications or you don't. It is not something that you
    switch off as you go off to lunch.
    A compile parameter, OTOH, would be too restrictive since it would force
    distros to choose just one behaviour (which would mean they would have
    to choose the most conservative).

    Trond

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Thu, 04 Oct 2007 10:00:50 -0400
    Trond Myklebust wrote:

    > On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote:
    > > On Wed, 03 Oct 2007 19:41:16 -0400
    > > Trond Myklebust wrote:
    > >
    > > >
    > > > We also have the 64-bit inode support from RedHat/Peter Staubach.
    > > >

    > >
    > > As has been pointed[1] out[2], this will cause regressions for
    > > non-LFS applications (of which there are still lots and lots). This
    > > change should be in feature-removal (the "feature" being removed is
    > > legacy support for non-LFS applications using NFS servers that make
    > > full use of the protocol) and preferably accompanied with
    > > appropriate user space changes (e.g. compatibility option in glibc).
    > >
    > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=241348
    > > [2] http://marc.info/?l=linux-nfs&m=118701088726477&w=2
    > >
    > > Rgds

    >
    > How about a boot/module parameter to turn it on or off?
    >


    That would be perfect. It can even be in non-legacy mode by default,
    just as long as you can go back to the old behaviour when/if you run
    into a non-LFS application.

    > I don't see any point in having a sysctl for something like this:
    > either you have legacy applications or you don't. It is not something
    > that you switch off as you go off to lunch.
    > A compile parameter, OTOH, would be too restrictive since it would
    > force distros to choose just one behaviour (which would mean they
    > would have to choose the most conservative).
    >


    Agreed.

    Rgds
    --
    -- Pierre Ossman

    Linux kernel, MMC maintainer http://www.kernel.org
    PulseAudio, core developer http://pulseaudio.org
    rdesktop, core developer http://www.rdesktop.org
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Thu, 4 Oct 2007 18:43:04 +0200
    Pierre Ossman wrote:

    > On Thu, 04 Oct 2007 10:00:50 -0400
    > Trond Myklebust wrote:
    >
    > > On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote:
    > > > On Wed, 03 Oct 2007 19:41:16 -0400
    > > > Trond Myklebust wrote:
    > > >
    > > > >
    > > > > We also have the 64-bit inode support from RedHat/Peter Staubach.
    > > > >
    > > >
    > > > As has been pointed[1] out[2], this will cause regressions for
    > > > non-LFS applications (of which there are still lots and lots). This
    > > > change should be in feature-removal (the "feature" being removed is
    > > > legacy support for non-LFS applications using NFS servers that make
    > > > full use of the protocol) and preferably accompanied with
    > > > appropriate user space changes (e.g. compatibility option in glibc).
    > > >
    > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=241348
    > > > [2] http://marc.info/?l=linux-nfs&m=118701088726477&w=2
    > > >
    > > > Rgds

    > >
    > > How about a boot/module parameter to turn it on or off?
    > >

    >
    > That would be perfect. It can even be in non-legacy mode by default,
    > just as long as you can go back to the old behaviour when/if you run
    > into a non-LFS application.
    >


    Wouldn't a mount option be better?
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Thu, 2007-10-04 at 11:42 -0700, Andrew Morton wrote:
    > On Thu, 4 Oct 2007 18:43:04 +0200
    > Pierre Ossman wrote:
    >
    > > On Thu, 04 Oct 2007 10:00:50 -0400
    > > Trond Myklebust wrote:
    > >
    > > > On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote:
    > > > > On Wed, 03 Oct 2007 19:41:16 -0400
    > > > > Trond Myklebust wrote:
    > > > >
    > > > > >
    > > > > > We also have the 64-bit inode support from RedHat/Peter Staubach.
    > > > > >
    > > > >
    > > > > As has been pointed[1] out[2], this will cause regressions for
    > > > > non-LFS applications (of which there are still lots and lots). This
    > > > > change should be in feature-removal (the "feature" being removed is
    > > > > legacy support for non-LFS applications using NFS servers that make
    > > > > full use of the protocol) and preferably accompanied with
    > > > > appropriate user space changes (e.g. compatibility option in glibc).
    > > > >
    > > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=241348
    > > > > [2] http://marc.info/?l=linux-nfs&m=118701088726477&w=2
    > > > >
    > > > > Rgds
    > > >
    > > > How about a boot/module parameter to turn it on or off?
    > > >

    > >
    > > That would be perfect. It can even be in non-legacy mode by default,
    > > just as long as you can go back to the old behaviour when/if you run
    > > into a non-LFS application.
    > >

    >
    > Wouldn't a mount option be better?


    I suppose that might be OK if you know that the 32-bit legacy
    applications will only touch one or two servers, but that sounds like a
    niche thing.

    On the downside, forcing all those people who have portable 64-bit aware
    applications to upgrade their version of mount just in order to have
    stat64() work correctly seems unnecessarily complicated. I'd prefer not
    to have to do that unless someone comes up with a good reason why we
    must.

    Cheers
    Trond

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    Trond Myklebust wrote:
    > On Thu, 2007-10-04 at 11:42 -0700, Andrew Morton wrote:
    >
    >> On Thu, 4 Oct 2007 18:43:04 +0200
    >> Pierre Ossman wrote:
    >>
    >>
    >>> On Thu, 04 Oct 2007 10:00:50 -0400
    >>> Trond Myklebust wrote:
    >>>
    >>>
    >>>> On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote:
    >>>>
    >>>>> On Wed, 03 Oct 2007 19:41:16 -0400
    >>>>> Trond Myklebust wrote:
    >>>>>
    >>>>>
    >>>>>> We also have the 64-bit inode support from RedHat/Peter Staubach.
    >>>>>>
    >>>>>>
    >>>>> As has been pointed[1] out[2], this will cause regressions for
    >>>>> non-LFS applications (of which there are still lots and lots). This
    >>>>> change should be in feature-removal (the "feature" being removed is
    >>>>> legacy support for non-LFS applications using NFS servers that make
    >>>>> full use of the protocol) and preferably accompanied with
    >>>>> appropriate user space changes (e.g. compatibility option in glibc).
    >>>>>
    >>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=241348
    >>>>> [2] http://marc.info/?l=linux-nfs&m=118701088726477&w=2
    >>>>>
    >>>>> Rgds
    >>>>>
    >>>> How about a boot/module parameter to turn it on or off?
    >>>>
    >>>>
    >>> That would be perfect. It can even be in non-legacy mode by default,
    >>> just as long as you can go back to the old behaviour when/if you run
    >>> into a non-LFS application.
    >>>
    >>>

    >> Wouldn't a mount option be better?
    >>

    >
    > I suppose that might be OK if you know that the 32-bit legacy
    > applications will only touch one or two servers, but that sounds like a
    > niche thing.
    >
    > On the downside, forcing all those people who have portable 64-bit aware
    > applications to upgrade their version of mount just in order to have
    > stat64() work correctly seems unnecessarily complicated. I'd prefer not
    > to have to do that unless someone comes up with a good reason why we
    > must.


    I would agree. The 64 bit fileids will only become visible when
    the server is exporting file systems which contain fileids which
    are bigger than 32 bits and then only when the application
    encounters these files.

    Also, these 32-bit legacy applications are going to have a
    problem if they are ever run on a system which contains local
    file systems which expose the large fileids.

    It would be better to identify these applications and get them
    fixed. The world is evolving and it is time for them to do so.

    ps
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Thu, 04 Oct 2007 15:16:03 -0400
    Trond Myklebust wrote:

    > > >
    > > > That would be perfect. It can even be in non-legacy mode by default,
    > > > just as long as you can go back to the old behaviour when/if you run
    > > > into a non-LFS application.
    > > >

    > >
    > > Wouldn't a mount option be better?

    >
    > I suppose that might be OK if you know that the 32-bit legacy
    > applications will only touch one or two servers, but that sounds like a
    > niche thing.
    >
    > On the downside, forcing all those people who have portable 64-bit aware
    > applications to upgrade their version of mount just in order to have
    > stat64() work correctly seems unnecessarily complicated. I'd prefer not
    > to have to do that unless someone comes up with a good reason why we
    > must.


    Confused. You don't need to modify mount(8) when adding a new mount option?
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Thu, 2007-10-04 at 12:59 -0700, Andrew Morton wrote:
    > On Thu, 04 Oct 2007 15:16:03 -0400
    > Trond Myklebust wrote:
    >
    > > > >
    > > > > That would be perfect. It can even be in non-legacy mode by default,
    > > > > just as long as you can go back to the old behaviour when/if you run
    > > > > into a non-LFS application.
    > > > >
    > > >
    > > > Wouldn't a mount option be better?

    > >
    > > I suppose that might be OK if you know that the 32-bit legacy
    > > applications will only touch one or two servers, but that sounds like a
    > > niche thing.
    > >
    > > On the downside, forcing all those people who have portable 64-bit aware
    > > applications to upgrade their version of mount just in order to have
    > > stat64() work correctly seems unnecessarily complicated. I'd prefer not
    > > to have to do that unless someone comes up with a good reason why we
    > > must.

    >
    > Confused. You don't need to modify mount(8) when adding a new mount option?


    Prior to 2.6.22, the 'mount' program used a binary blob for passing the
    NFS mount options to the kernel.
    It is only very recently that we have started doing in-kernel parsing of
    text strings, and in order to make use of that, people will need to
    upgrade to the latest version of nfs-utils.

    Trond

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Thu, 04 Oct 2007 15:41:57 -0400
    Peter Staubach wrote:

    >
    > I would agree. The 64 bit fileids will only become visible when
    > the server is exporting file systems which contain fileids which
    > are bigger than 32 bits and then only when the application
    > encounters these files.
    >


    Or, as has been pointed out, when the server is not the Linux in-kernel
    NFS server.

    > Also, these 32-bit legacy applications are going to have a
    > problem if they are ever run on a system which contains local
    > file systems which expose the large fileids.
    >


    Agreed. And I'd probably like a way around that as well. But local
    files have never worked, NFS has. So removing it from NFS (where it is
    more likely to occur IMO) would be a regression.

    > It would be better to identify these applications and get them
    > fixed. The world is evolving and it is time for them to do so.
    >


    Print a warning or something so that they can be found. Don't go
    breaking systems left and right. People have better things to do than
    to fix the build systems for ever program they use.

    Rgds
    --
    -- Pierre Ossman

    Linux kernel, MMC maintainer http://www.kernel.org
    PulseAudio, core developer http://pulseaudio.org
    rdesktop, core developer http://www.rdesktop.org
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Fri, 2007-10-05 at 08:25 +0200, Pierre Ossman wrote:

    > Print a warning or something so that they can be found. Don't go
    > breaking systems left and right. People have better things to do than
    > to fix the build systems for ever program they use.


    The kernel knows bugger all about what glibc function your program is
    calling. The problem here is precisely that newer versions of glibc will
    transform legacy 32-bit stat() calls into 64-bit stat64() calls, then
    will complain when the result overflows.

    If you want to figure out which apps are broken, then you will have to
    either do so in glibc or use a preloaded shared library to intercept the
    32-bit stat() calls and print out a warning.

    Trond

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Thu, 04 Oct 2007 10:00:50 EDT, Trond Myklebust said:

    > How about a boot/module parameter to turn it on or off?
    >
    > I don't see any point in having a sysctl for something like this: either
    > you have legacy applications or you don't. It is not something that you
    > switch off as you go off to lunch.


    How does Joe Sysadmin tell if he has an affected legacy app or not?

    (The obvious "try it and see what breaks" is a non-starter for many places,
    because you too easily end up in a loop of "enable it, find 4-5 show stoppers,
    turn it off, fix them, lather rinse repease". Been there, done that, got
    the tshirt - a project I got dragged into involves a large storage array that
    appears to insist on exporting 64-bit stuff, and a large farm of clients that
    are very 64-bit unclean....)

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.7 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHBnSicC3lWbTT17ARAguhAJ4yFFwmHh6NzutHLK6SsM d4NATjhACeJysn
    kycLaBtXZeeZfLAErtMYu1E=
    =VK65
    -----END PGP SIGNATURE-----


  14. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Fri, 2007-10-05 at 13:30 -0400, Valdis.Kletnieks@vt.edu wrote:
    > On Thu, 04 Oct 2007 10:00:50 EDT, Trond Myklebust said:
    >
    > > How about a boot/module parameter to turn it on or off?
    > >
    > > I don't see any point in having a sysctl for something like this: either
    > > you have legacy applications or you don't. It is not something that you
    > > switch off as you go off to lunch.

    >
    > How does Joe Sysadmin tell if he has an affected legacy app or not?
    >
    > (The obvious "try it and see what breaks" is a non-starter for many places,
    > because you too easily end up in a loop of "enable it, find 4-5 show stoppers,
    > turn it off, fix them, lather rinse repease". Been there, done that, got
    > the tshirt - a project I got dragged into involves a large storage array that
    > appears to insist on exporting 64-bit stuff, and a large farm of clients that
    > are very 64-bit unclean....)


    If you're unsure, then set the bloody boot parameter. That's what it is
    for...

    Trond

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Fri, 05 Oct 2007 13:36:19 -0400
    Trond Myklebust wrote:

    > On Fri, 2007-10-05 at 08:25 +0200, Pierre Ossman wrote:
    >
    > > Print a warning or something so that they can be found. Don't go
    > > breaking systems left and right. People have better things to do
    > > than to fix the build systems for ever program they use.

    >
    > The kernel knows bugger all about what glibc function your program is
    > calling. The problem here is precisely that newer versions of glibc
    > will transform legacy 32-bit stat() calls into 64-bit stat64() calls,
    > then will complain when the result overflows.
    >


    Right, I didn't suggest that this had to be done in the kernel. My
    point was that first you mark something as deprecated, make a lot of
    noise when someone uses it so that problems can be identified, and some
    time later you remove it. You don't just remove it and let production
    systems deal with the fallout.

    Rgds
    --
    -- Pierre Ossman

    Linux kernel, MMC maintainer http://www.kernel.org
    PulseAudio, core developer http://pulseaudio.org
    rdesktop, core developer http://www.rdesktop.org
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Fri, 05 Oct 2007 13:30:10 -0400
    Valdis.Kletnieks@vt.edu wrote:
    >
    > How does Joe Sysadmin tell if he has an affected legacy app or not?
    >
    > (The obvious "try it and see what breaks" is a non-starter for many places,
    > because you too easily end up in a loop of "enable it, find 4-5 show stoppers,
    > turn it off, fix them, lather rinse repease". Been there, done that, got
    > the tshirt - a project I got dragged into involves a large storage array that
    > appears to insist on exporting 64-bit stuff, and a large farm of clients that
    > are very 64-bit unclean....)
    >


    In addition to Trond's suggestion, you might be able to use "nm" or
    something like it and see if there are references to non-LFS (f)stat
    calls in your binaries. For instance, if you see references to stat()
    (and not stat64()), then the app is probably not built with 64-bit file
    offsets.

    This is probably not as reliable as Trond's method, but it might be
    less invasive and reasonable for a first pass when looking for these
    sorts of apps...

    --
    Jeff Layton
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Fri, 05 Oct 2007 13:30:10 -0400
    Valdis.Kletnieks@vt.edu wrote:

    > On Thu, 04 Oct 2007 10:00:50 EDT, Trond Myklebust said:
    >
    > > How about a boot/module parameter to turn it on or off?
    > >
    > > I don't see any point in having a sysctl for something like this: either
    > > you have legacy applications or you don't. It is not something that you
    > > switch off as you go off to lunch.

    >
    > How does Joe Sysadmin tell if he has an affected legacy app or not?
    >
    > (The obvious "try it and see what breaks" is a non-starter for many places,
    > because you too easily end up in a loop of "enable it, find 4-5 show stoppers,
    > turn it off, fix them, lather rinse repease". Been there, done that, got
    > the tshirt - a project I got dragged into involves a large storage array that
    > appears to insist on exporting 64-bit stuff, and a large farm of clients that
    > are very 64-bit unclean....)
    >


    Note that "try it and see what breaks" isn't reliable either. If glibc
    gets back a 64 bit inode number that just happens to fit in the 32-bit
    field, then everything will work. You don't actually get an EOVERFLOW
    until st_ino overflows the field, and that may not happen often enough
    for testing this way to detect it...


    --
    Jeff Layton
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Fri, Oct 05, 2007 at 02:12:22PM -0400, Jeff Layton wrote:
    > On Fri, 05 Oct 2007 13:30:10 -0400
    > Valdis.Kletnieks@vt.edu wrote:
    >
    > > On Thu, 04 Oct 2007 10:00:50 EDT, Trond Myklebust said:
    > >
    > > > How about a boot/module parameter to turn it on or off?
    > > >
    > > > I don't see any point in having a sysctl for something like this: either
    > > > you have legacy applications or you don't. It is not something that you
    > > > switch off as you go off to lunch.

    > >
    > > How does Joe Sysadmin tell if he has an affected legacy app or not?
    > >
    > > (The obvious "try it and see what breaks" is a non-starter for many places,
    > > because you too easily end up in a loop of "enable it, find 4-5 show stoppers,
    > > turn it off, fix them, lather rinse repease". Been there, done that, got
    > > the tshirt - a project I got dragged into involves a large storage array that
    > > appears to insist on exporting 64-bit stuff, and a large farm of clients that
    > > are very 64-bit unclean....)
    > >

    >
    > Note that "try it and see what breaks" isn't reliable either. If glibc
    > gets back a 64 bit inode number that just happens to fit in the 32-bit
    > field, then everything will work. You don't actually get an EOVERFLOW
    > until st_ino overflows the field, and that may not happen often enough
    > for testing this way to detect it...


    There's a damn easy way of testing this.

    Use XFS on a 64 bit Linux NFS server, mount is '-o inode64,ino64'
    and then export it to you client that is going to have problems.
    the "ino64" mount option guarantees that the userspace visible
    inode number is always > 32 bits in length....

    Cheers,

    Dave.
    --
    Dave Chinner
    Principal Engineer
    SGI Australian Software Group
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [NFS] What's slated for inclusion in 2.6.24-rc1 from the NFS client git tree...

    On Fri, Oct 05, 2007 at 02:00:37PM -0400, Jeff Layton wrote:
    > On Fri, 05 Oct 2007 13:30:10 -0400
    > Valdis.Kletnieks@vt.edu wrote:
    > >
    > > How does Joe Sysadmin tell if he has an affected legacy app or not?
    > >
    > > (The obvious "try it and see what breaks" is a non-starter for many places,
    > > because you too easily end up in a loop of "enable it, find 4-5 show stoppers,
    > > turn it off, fix them, lather rinse repease". Been there, done that, got
    > > the tshirt - a project I got dragged into involves a large storage array that
    > > appears to insist on exporting 64-bit stuff, and a large farm of clients that
    > > are very 64-bit unclean....)
    > >

    >
    > In addition to Trond's suggestion, you might be able to use "nm" or
    > something like it and see if there are references to non-LFS (f)stat
    > calls in your binaries. For instance, if you see references to stat()
    > (and not stat64()), then the app is probably not built with 64-bit file
    > offsets.


    Attached is a Perl script I wrote a while back to scan directories
    looking for old stat calls in binaries. Here's the output from
    my laptop:

    # ./summarise-stat64.pl /usr/bin
    775 26.8% are scripts (shell, perl, whatever)
    1404 48.5% don't use any stat() family calls at all
    428 14.8% use 32-bit stat() family interfaces only
    278 9.6% use 64-bit stat64() family interfaces only
    11 0.4% use both 32-bit and 64-bit stat() family interfaces

    # ./summarise-stat64.pl /usr/sbin
    164 35.7% are scripts (shell, perl, whatever)
    170 37.0% don't use any stat() family calls at all
    78 17.0% use 32-bit stat() family interfaces only
    46 10.0% use 64-bit stat64() family interfaces only
    1 0.2% use both 32-bit and 64-bit stat() family interfaces

    # ./summarise-stat64.pl -v /usr/bin
    ....
    /usr/bin/vi use 32-bit stat() family interfaces only
    /usr/bin/view use 32-bit stat() family interfaces only
    /usr/bin/vim use 32-bit stat() family interfaces only
    ....
    /usr/bin/Mail use 32-bit stat() family interfaces only
    /usr/bin/mail use 32-bit stat() family interfaces only
    /usr/bin/mailx use 32-bit stat() family interfaces only
    ....
    /usr/bin/gdb use 32-bit stat() family interfaces only
    /usr/bin/gdbtui use 32-bit stat() family interfaces only
    /usr/bin/rpcgen use 32-bit stat() family interfaces only
    ....
    /usr/bin/cc use 32-bit stat() family interfaces only
    /usr/bin/gcc use 32-bit stat() family interfaces only
    /usr/bin/gcov use 32-bit stat() family interfaces only
    /usr/bin/unprotoize use 32-bit stat() family interfaces only
    ....
    /usr/bin/git use 32-bit stat() family interfaces only
    /usr/bin/git-check-ref-format use 32-bit stat() family interfaces only
    /usr/bin/git-cat-file use 32-bit stat() family interfaces only
    /usr/bin/git-checkout-index use 32-bit stat() family interfaces only
    /usr/bin/git-clone-pack use 32-bit stat() family interfaces only
    /usr/bin/git-commit-tree use 32-bit stat() family interfaces only
    /usr/bin/git-convert-objects use 32-bit stat() family interfaces only
    /usr/bin/git-daemon use 32-bit stat() family interfaces only
    /usr/bin/git-describe use 32-bit stat() family interfaces only
    ....

    Greg.
    --
    Greg Banks, R&D Software Engineer, SGI Australian Software Group.
    Apparently, I'm Bedevere. Which MPHG character are you?
    I don't speak for SGI.


+ Reply to Thread