[NCLUG] autofs behaviour

[Dave Treece]

Bob said something that sparked an old memory, something about "my what 
a log of nfs activity". A while back, in a production environment not 
far from Michael...We used NFS extensively for our environment. In our 
environment we were constantly writing to log files and such (which ends 
up being a multitude of very small writes and constant cache 
hits/flushes) which turns out is very hard on NFS and makes for a VERY 
busy NFS server. One of the symptoms we saw was very similar to what you 
describe in that occasionally we would get misses on file opens and 
such. We soon found that NFS works much better when you can write large 
blocks instead of many very small block and as such, we found that 
things worked much better to write locally and copy over NFS. Not sure 
if this helps you any or if it points to some fixable clue, but, you can 
take it for what its worth.



Bob Proulx wrote:
> Michael Coffman wrote:
>   
>> Bob Proulx wrote:
>>     
>>> date; while stat /net/hostname/test >/dev/null ; do :; done; date
>>>       
>> Hmmm..   The while loop never exits..   But I get an error at the dismount 
>> interval...
>>     
>
> Yes.  Strange.
>
>   
>>> It would be interesting to see by tcpdump and wireshark/ethereal that
>>> the nfs getattr calls are proceeding as expected.
>>>       
>> I am not really too sure about what to look for...  I ran the command:
>>
>>   tcpdump -v dst nfsserver
>>
>> on the client while running the command.  The output during the first run 
>> and up until the failure is attached...  (hope attachments are ok...)
>> The server name is nfsserver and the client name is nfsclient.
>>     
>
> At 318k that was a little large to send to a mailing list.  And
> unfortunately that type of output isn't really useful for this level
> of debug either.  The packets are summaries only.  I looked at it
> anyway and about that I can say is my what a lot of nfs activity.  :-)
>
> What I was thinking of was something along these lines.  Run tcpdump
> and save the raw data to a file.  Then run wireshark on the dump file.
>
>   tcpdump -lni any -s 0 -w /tmp/tcpdump.data host nfsserver
>
> The options decode as follows:
>
>  -i any  -- listen on any interface
>             any is linux specific option to listen to all interfaces
>             in non-promiscuous mode, so must imply -p
>  -n      -- no lookup of ip addresses, no names
>  -l      -- line buffered output
>  -s NUM  -- snarf num size packets, default 68, 0 means snarf entire
>
> But again that will be large so don't send that to the mailing list.
> But wireshark should be able to decode the packets and from this make
> human intelligence about it.  Maybe.  This doesn't actually mean it
> would tell us anything.  But something like that was what I was
> thinking when I said that.
>
>   
>>> Autofs 'host' maps are notorious for dropping single mount points from
>>> the set of all mount points on the host.  Is this a single mount point
>>> on a host or is this one of a dozen mount points on a host?  At some
>>>       
>> dozens :(   But I have also done the test with a single mount point
>> direct map with the same results...
>>     
>
> Okay.  Then it probably isn't a hostmap specific issue.
>
>   
>>> point (in the future still?) autofs starts to get smarter about mount
>>> points and will handle them individually instead of as a group.  That
>>> will be a good thing and should help with the dropped host mapped
>>> mount point problem.
>>>       
>> Are you implying that at some existing rev auto mount 'is' smarter
>> about this?
>>     
>
> Hmm...  Yes and no.  I believe the development code is already smarter
> about this but last I heard it wasn't ready for production use yet.
> But I haven't looked at it in ages and don't know if it is usable or
> not.  But as far as I know the development code behaves more like the
> HP-UX 11.31 (and 11.23 maybe?  I don't remember) in that with the host
> mapped autofs there disks are individually mounted and not done as a
> group.  A huge improvement.  If you have an HP-UX 11.31 system
> available poke around there and you will see that host mapped autofs
> mounts are smarter than they were previously.
>
>   
>>> slots.  So while amd v. autofs debates continue it is really just a
>>> different set of issues.  Depending on the problem one or the other
>>> will be the better choice but neither are best all around.
>>>       
>> I am currently using amd on clients, but it does not deal with slow nfs 
>> servers well.  When mountd on a server gets over run with requests and amd 
>> does not hear back in a timely way, I have systems that end up with only 
>> some or none of the mounts they were trying to get.
>>     
>
> Exactly!  On different tasks and in different environments either one
> or the other will be better but neither one is perfect all around.
>
> In the other email thread...
>   
>>> and soft mounts creates some quirky behavior that could possibly
>>>       
>> Interesting, but I'm not using soft mounts.  Here are the options form
>>     
>
> I advise avoiding soft mounts.  They can lead to silent data
> corruption due to scripts that have their computational model broken
> as compared with local filesystems.  Using a soft nfs mount when it is
> slow and unreliable will produce I/O errors in a way similar to trying
> to run on a failing hard drive.  Almost no one bulletproofs their
> scripts and programs for that type of environment.
>
> Here is the description from the mount man page with a comment that I
> also agree with.
>
>        soft   This option allows the kernel to time out if the nfs  server  is
>               not  responding  for  some  time. The time can be specified with
>               timeo=time.  This option might be  useful  if  your  nfs  server
>               sometimes doesn’t respond or will be rebooted while some process
>               tries to get a file from the server.   Usually  it  just  causes
>               lots of trouble.
>
> Bob
> _______________________________________________
> NCLUG mailing list       NCLUG at nclug.org
>
> To unsubscribe, subscribe, or modify 
> your settings, go to: 
> http://www.nclug.org/mailman/listinfo/nclug
>
>