Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Dec 2012 15:36:09 -0500 (EST)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Tim Gustafson <tjg@soe.ucsc.edu>
Cc:        FreeBSD Filesystems <freebsd-fs@freebsd.org>
Subject:   Re: NFS Problems
Message-ID:  <910429574.1528413.1356035769195.JavaMail.root@erie.cs.uoguelph.ca>
In-Reply-To: <CAG27QgT1gWYAKa5H0hTuEM2zWWbE62s9GM1ibepOoZLZ_JAzrw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Tim Gustafson wrote:
> Just yesterday, we moved our user home directories from a Sun file
> server
> to a FreeBSD file server. We've had a few hiccups and burps, but
> mostly
> things seem to be running OK right now. However, some of our Linux
> clients
> who are running Firefox are having problems, and I think I've narrowed
> it
> down to a problem with fcntl64() and I'm including a snippet of strace
> output from the Linux client below:
> 
> stat64("/soe/tjg/.mozilla/firefox/105gir0j.default/places.sqlite",
> {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> open("/soe/tjg/.mozilla/firefox/105gir0j.default/places.sqlite",
> O_RDWR|O_CREAT|O_LARGEFILE, 0644) = 31
> fcntl64(31, F_GETFD) = 0
> fcntl64(31, F_SETFD, FD_CLOEXEC) = 0
> fstat64(31, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
> clock_gettime(CLOCK_MONOTONIC, {4584, 334732510}) = 0
> clock_gettime(CLOCK_MONOTONIC, {4584, 334902510}) = 0
> clock_gettime(CLOCK_MONOTONIC, {4584, 335084510}) = 0
> _llseek(31, 0, [0], SEEK_SET) = 0
> read(31, "", 100) = 0
> clock_gettime(CLOCK_MONOTONIC, {4584, 335584510}) = 0
> fcntl64(31, 0xd /* F_??? */, 0xffde28b4) = -1 EIO (Input/output error)
0xd -> 13, which is F_SETLK64 I believe.

> close(31) = 0
> 
> That last call to fcntl64() hangs for several seconds before moving
> on, and
> the fcntl64() function gets called on several different files (like
> the
> ,parentlock file, for example) and always takes a while and seemingly
> always reports the input/output error. Eventually a Firefox window
> does
> appear to the user, but it's totally non-responsive.
> 
> I'd be happy to give the full strace output to anyone who's interested
> to
> see.
> 
> If I set the nolock option on the nfs mount, Firefox starts
> successfully.
> 
Sounds like you've solved your problem. Unless the same file is being
locked concurrently by multiple clients, just use "nolock".

> lockd and statd are running on both the Linux client and the FreeBSD
> server.
> 
These protocols are just a trainwreck looking for a place to happen, imho.
(I don't know if the FreeBSD lockd supports 64bit locking or not?)

If you need locking to work, I'd suggest you try NFSv4.

> Any pointers as to what might be causing this?
> 
If you really want to get lockd working, the starting point would be
capturing packets when the problem occurs and taking a look at them
in wireshark, to see exactly what is failing. (I suspect it's an NLM
RPC, but...)

rick

> --
> 
> Tim Gustafson
> tjg@soe.ucsc.edu
> 831-459-5354
> Baskin Engineering, Room 313A
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?910429574.1528413.1356035769195.JavaMail.root>