Re: [PATCH] nfs-utils 1 of 10 - Removed sync warning on readonly exports

[Steve Dickson <SteveD@redhat.com>]

Neil Brown wrote:
> Thanks Steve (and sorry about the delay).
np...

> I've incorporated some of them into SourceForge CVS 
Excellent! The more I can get in your world the less I need
to keep in mine... ;-)

> 
>  "[NFS] [PATCH] nfs-utils 2 of 10 - Incorporate some clean up code from Ulrich Drepper"
>    I re-wrote this with a separate function 'closeall' which is called
>    from various places.  
Cool...

>    The 'signal' changes I left out because there was no explanatory
>    text :-)
yeah, our glibc guys notice the fact we weren't using the newer
signal management API (i.e. setset()) and for some reason
(which I can't remember at the moment) they thought that was bad.
I'll ping them and ask what their reason was...

> 
>  "[NFS] [PATCH] nfs-utils 3 of 10 - Make sure check_new_cache() looks in the right place"
>    I think the change to check_new_cache is wrong.  It really needs to
>    check if /proc/fs/nfs{,d} is mounted, and it doesn't do that any
>    more.
Well why should mountd and exportfs care if /proc/fs/nfs exists?
Maybe I'm missing something, but it appears that all the cache_XXX
routines only need the auth.unix.ip, nfsd.export, and nfsd.fh files
that are in /proc/fs/nfsd. So I thought it made sense that
check_new_cache() should run through a file list (similar to what the
other cache_XXX routines do) making sure those files exist. With the
obvious point being, if those files do exist, the filesystem is mounted.


> 
>  "[NFS] [PATCH] nfs-utils 7 of 10 - Changed mountd to use stat64()"
>    Not included. 
>    Can you say more about:
> 
>            I wonder if it would be better just to make mountd a 64bit
>            application by compiling with -D_FILE_OFFSET_BITS=64?
> 
>    I thought that when you compiled with a newer glibc, you
>    automagically got 64bit stuff...
Even on 32bit machine? I thought you had to explicitly ask the
complier for 64bit offsets...  Anyways, this patch stop
rpc.mountd from failing when a file > 2g was mounted.
(i.e. 'mount server:/export/3gigfile /mnt/3gigfile' would cause
rpc.mountd to fail with with "Value too large for defined data type").

My fix was was to change all the stat() calls to stat64() calls
which fix the problem. But I was wondering if it made more sense
to back out my patch and simply compile with the
-D_FILE_OFFSET_BITS=64 compile flag....


> 
>  "[NFS] [PATCH] nfs-utils 8 of 10 - added the command line arguments to rpc.nfsd"
>    Not included.  Uses functionality specific to redhat kernel.
> 
Right... but the patch is not depended on any particular kernel.
Meaning rpc.nfsd, with this patch, will function correctly
with or without the kernel patch...


>  - re-open the debate on specifying version/protocol option to the
>    kernel,
> 
> I am all ears.
Good... I'll post the latest version asap...

steved.


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs