After browsing the whole bookshelves, mailinglists, FAQs etc. I havn't found
an answer to my following problem:
I'm trying to export a striped LSM volume via NFS with about 15 GB diskspace
(this will increase in the future).
Mounting/Unmounting this volume (either with ufs on top, or advfs, I tried both)
from a client works fine. But... when I climb down the directory-tree
the server gets in an endless-loop calling statfs() after the first few (3-4)
directory-levels.
On the client I get
"NFS3 server fraggle not responding still trying"
which seems to be normal, since tcpdump tells me the following:
##### on the client:
##### mount -t nfs fraggle:/project /tmp/test
##### ls -l /tmp/test/hybridis
# tcpdump -N -s 194 -v -i fta0 host missmarple
tcpdump: listening on fta0
Using kernel BPF filter
10:42:30.458720 snap ip missmarple.969 > fraggle.111: udp 56 (ttl 30, id 58442)
10:42:30.461648 snap ip missmarple.970 > fraggle.111: udp 56 (ttl 30, id 58443)
10:42:30.464576 snap ip missmarple.971 > fraggle.1026: udp 136 (ttl 30, id
58444)
10:42:30.468480 snap ip missmarple.36eff9d > fraggle.nfs: 160 getattr [|nfs]
(ttl 30, id 58445)
10:42:30.470432 snap ip missmarple.46eff9d > fraggle.nfs: 160 proc-19 (ttl 30,
id 58446)
10:42:30.472384 snap ip missmarple.56eff9d > fraggle.nfs: 160 proc-18 (ttl 30,
id 58447)
10:42:54.238144 snap arp arp who-has fraggle tell missmarple
10:42:54.239120 snap ip missmarple.906eff9d > fraggle.nfs: 172 root [|nfs] (ttl
30, id 58610)
10:42:54.242048 snap ip missmarple.916eff9d > fraggle.nfs: 164 lookup [|nfs]
(ttl 30, id 58611)
10:42:54.244000 snap ip missmarple.926eff9d > fraggle.nfs: 164 lookup [|nfs]
(ttl 30, id 58612)
10:42:54.245952 snap ip missmarple.936eff9d > fraggle.nfs: 160 getattr [|nfs]
(ttl 30, id 58613)
10:42:54.248880 snap ip missmarple.946eff9d > fraggle.nfs: 184 statfs [|nfs]
(ttl 30, id 58614)
10:42:54.251808 snap ip missmarple.956eff9d > fraggle.nfs: 168 root [|nfs] (ttl
30, id 58615)
10:42:54.254736 snap ip missmarple.966eff9d > fraggle.nfs: 164 lookup [|nfs]
(ttl 30, id 58616)
10:43:04.052704 snap ip missmarple.d06eff9d > fraggle.nfs: 160 getattr [|nfs]
(ttl 30, id 58685)
10:43:04.054656 snap ip missmarple.d26eff9d > fraggle.nfs: 180 readdir [|nfs]
(ttl 30, id 58687)
##### up to here, everything seems to work fine.
##### here comes the next directory level:
##### ls -l /tmp/test/hybridis/images on the client:
10:43:13.859856 snap ip missmarple.b6fff9d > fraggle.nfs: 164 lookup [|nfs] (ttl
30, id 58754)
10:43:13.861808 snap ip missmarple.c6fff9d > fraggle.nfs: 160 getattr [|nfs]
(ttl 30, id 58755)
10:43:13.863760 snap ip missmarple.d6fff9d > fraggle.nfs: 184 statfs [|nfs] (ttl
30, id 58756)
10:43:15.113216 snap ip missmarple.d6fff9d > fraggle.nfs: 184 statfs [|nfs] (ttl
30, id 58764)
10:43:17.611952 snap ip missmarple.d6fff9d > fraggle.nfs: 184 statfs [|nfs] (ttl
30, id 58786)
10:43:22.611952 snap ip missmarple.d6fff9d > fraggle.nfs: 184 statfs [|nfs] (ttl
30, id 58823)
... and so on, and so on.
exporting a 7 GB volume works fine, I havn't tested decreasing the size of the
15 GB volume, but I tried the following setups:
server: Digital UNIX 3.2C (148), exporting 15 GB LSM ufs formatted via NFS
server: Digital UNIX 3.2C (148), exporting 15 GB LSM advfs formatted via NFS
client: Digital UNIX 3.2C (148), importing via mount -t nfs or automount
client: OSF1 V3.0 (347) , importing via mount -t nfs or automount
Locally (on the serverside) there is no problem accessing the files, no matter
how deep.
It seems, that the tree-level depths isn't the problem either: creating
something like:
mkdirhier /project/a/b/c/d/e/f/g/h
...lets me access all the dirs without problems.
but copying a directory containing files to /project/a/b/
leaves me hanging around, staring at tcpdump telling me
nfs is doing a statfs(). The maximum filesize isn't breaking
the 2GB nfs-frontier, so this shouldn't be a problem.
all these problems only occur on the exported 15 GB volume,
no matter which filesystem i use. all other nfs exports/imports
work fine, there are no special options or modifications done.
I would be pleased, if someone could give me hints how to "fix"
this. to decrease the volume size seems to be a solution, but not in
my special case. I really need to export volumes of this size.
answers/hints/"forget it"s/"This is a kernel-bug"s/"get patch xxxx"s
anyone ?
Thanks in advance,
Peter Marquardt
##===========================##============================================##
Dipl.Ing. Peter Marquardt/// SysAdmim Max-Planck-Institute Molecular Genetics
|| /// || --==> Earth-Germany-Berlin-Dahlem <==-- ||
:: +49-30-8413-1230 \\\/// :: marquardt_p_at_mpimg-berlin-dahlem.mpg.de ::
.. wwwutz on IRC \XX/A4k .. marquardt_p_at_fhi-berlin.mpg.de ..
..===========================..============================================..
Received on Thu Nov 23 1995 - 12:19:17 NZDT