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.cgi?p=nfs-2.6.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
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
On Wed, 03 Oct 2007 19:41:16 -0400
Trond Myklebust <[email protected]> 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
On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote:
> On Wed, 03 Oct 2007 19:41:16 -0400
> Trond Myklebust <[email protected]> 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
On Thu, 04 Oct 2007 10:00:50 -0400
Trond Myklebust <[email protected]> wrote:
> On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote:
> > On Wed, 03 Oct 2007 19:41:16 -0400
> > Trond Myklebust <[email protected]> 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
On Thu, 4 Oct 2007 18:43:04 +0200
Pierre Ossman <[email protected]> wrote:
> On Thu, 04 Oct 2007 10:00:50 -0400
> Trond Myklebust <[email protected]> wrote:
>
> > On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote:
> > > On Wed, 03 Oct 2007 19:41:16 -0400
> > > Trond Myklebust <[email protected]> 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?
On Thu, 2007-10-04 at 11:42 -0700, Andrew Morton wrote:
> On Thu, 4 Oct 2007 18:43:04 +0200
> Pierre Ossman <[email protected]> wrote:
>
> > On Thu, 04 Oct 2007 10:00:50 -0400
> > Trond Myklebust <[email protected]> wrote:
> >
> > > On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote:
> > > > On Wed, 03 Oct 2007 19:41:16 -0400
> > > > Trond Myklebust <[email protected]> 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
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 <[email protected]> wrote:
>>
>>
>>> On Thu, 04 Oct 2007 10:00:50 -0400
>>> Trond Myklebust <[email protected]> wrote:
>>>
>>>
>>>> On Thu, 2007-10-04 at 08:52 +0200, Pierre Ossman wrote:
>>>>
>>>>> On Wed, 03 Oct 2007 19:41:16 -0400
>>>>> Trond Myklebust <[email protected]> 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
On Thu, 04 Oct 2007 15:16:03 -0400
Trond Myklebust <[email protected]> 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?
On Thu, 2007-10-04 at 12:59 -0700, Andrew Morton wrote:
> On Thu, 04 Oct 2007 15:16:03 -0400
> Trond Myklebust <[email protected]> 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
On Thu, 04 Oct 2007 15:41:57 -0400
Peter Staubach <[email protected]> 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
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....)
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
On Fri, 2007-10-05 at 13:30 -0400, [email protected] 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
On Fri, 05 Oct 2007 13:36:19 -0400
Trond Myklebust <[email protected]> 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
On Fri, 05 Oct 2007 13:30:10 -0400
[email protected] 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 <[email protected]>
On Fri, 05 Oct 2007 13:30:10 -0400
[email protected] 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 <[email protected]>
On Fri, Oct 05, 2007 at 02:12:22PM -0400, Jeff Layton wrote:
> On Fri, 05 Oct 2007 13:30:10 -0400
> [email protected] 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
On Fri, Oct 05, 2007 at 02:00:37PM -0400, Jeff Layton wrote:
> On Fri, 05 Oct 2007 13:30:10 -0400
> [email protected] 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.