Re: NFS mounts not largefiles by default?

From: CJT (abujlehc_at_prodigy.net)
Date: 07/10/04 

Date: Sat, 10 Jul 2004 01:44:59 GMT

Darren Dunham wrote:

> CJT <abujlehc@prodigy.net> wrote:
>
>>OK, I'm using whatever NFS is the default in Solaris 9. The reason
>>I thought I had found the problem is that when I did a mount -v on
>>the client, it did not show largefiles for the remote mounts, but did
>>for the local mounts.
>
>
> That's simply because there is no such mount option for nfs filesystems.
>
>
>>And, as I said in the original post, umounting that drive (whose only
>>file is the newly created large one) suddenly and spectacularly freed
>>up several terminal sessions on the console which appeared to be hung
>>and also suddenly caused my Sun Rays to again become responsive.
>
>
> Did you have to force the unmount? Were there processes that had the
> filesystem open or in use? Did killing those processes not clear the
> hang?
>
>
>>The
>>only thing common between the hung sessions is that they all somehow
>>were accessing the directory containing the mount point of the culprit
>>drive -- they should not have been accessing the drive itself, just
>>its mount point. I couldn't even ls the directory containing its
>>mount point.
>
>
> Is the automounter involved here at all?
>

Thanks for your help. Here's some further information.

This is my household system.

The file server is Solaris 9 X86 and the client is Solaris 9 on an
Ultra 2. The file server provides system-wide home directories and some
mostly multimedia files which are on separate disks. The Ultra serves
three Sun Rays, and I don't normally use its console, just the Rays.
The X86's patches are current and the Ultra's patches are about a month
old.

Several disks for multimedia on the server are mounted on the client via
/etc/vfstab to mount points which are all in one directory. The home
directories are on a separate disk. I recently added another multimedia
disk (the apparent culprit, and why the patches are up to date) and it
contains only one file put there via Samba from a PC; it's a full
multi-GB backup of the PC at which I'm sitting, and shouldn't have been
in use by any process at the time. FWIW, it's a 250 GB disk, but not
the only such drive on the system.

I think the first sign of a problem was when I tried to change music
files under XMMS (which I use as a player) and it hung the Ray totally
(I couldn't get any response). I went to a second Ray and logged in;
when I tried to start XMMS it would not open. So I went to the Ultra
and logged in as root (on the Rays I was a normal user). I opened a
terminal window and, suspecting something having to do with the
multimedia files, I tried to cd to the directory containing their mount
points. That terminal window hung. I opened a second and did a df.
That terminal window hung just above the point where I expected to see
the stats for the new disk. I let things sit for 5 or ten minutes to
see if it was just slow, and nothing changed. At that point I had the
clever idea to open a third terminal window and umount the new disk.
When I did, the first Ray started again to respond and the second Ray
could now open XMMS. The two hung terminal windows showed the results
of the cd and df I had attempted. And that's when I started looking
for what might be different about that particular disk. Since it only
has one file on it, the inquiry was short. The only things I could
think of that would make this drive special are that it was >137GB
(but so is another I've not had any problems with) and it contains a
large file (hence this thread). I've remounted the disk and the
problem has not happened again, but I'd like to learn from this if
possible.

The home directories are automounted, but not the multimedia disks.

I did not attempt to kill the first XMMS process, so don't know whether
that might have made a difference.

As I sit here writing this, I notice that the permissions on the mount
point for the new disk were 766 rather than 777 like its peers; I hope
something that silly isn't the problem. AFAIK I haven't done anything
that would require writing to that disk.

I hope that all makes sense. Your additional thoughts are appreciated. 

-- 
The e-mail address in our reply-to line is reversed in an attempt to
minimize spam.  Our true address is of the form che...@prodigy.net.
Loading