Hi Melbogia, On 09/03/10 18:08 -0800, melbogia wrote: > Hello, > We have a zfs filesystem exported as read-only to a subnet. Some of the > clients are able to mount the nfs share and read the data, others can mount > but when i do an 'ls' command it just sits there. I checked the server and > 'dmesg' shows lots of nfs errors like so > > Mar 9 06:06:24 fortress nfssrv: [ID 939466 kern.warning] WARNING: nfsauth: > mountd has not established door > Mar 9 06:12:49 fortress last message repeated 6 times > Mar 9 06:13:54 fortress nfssrv: [ID 939466 kern.warning] WARNING: nfsauth: > mountd has not established door > Mar 9 06:19:15 fortress last message repeated 5 times > Mar 9 06:20:19 fortress nfssrv: [ID 939466 kern.warning] WARNING: nfsauth: > mountd has not established door > Mar 9 06:25:40 fortress last message repeated 5 times > Mar 9 06:26:45 fortress nfssrv: [ID 939466 kern.warning] WARNING: nfsauth: > mountd has not established door > > I noticed that there are lots of mountd coredumps in / which I assume are > related to my nfs issue. I ran pstack on one of those files and got this. > > root at fortress:/# pstack core.mountd.1268185359 > core 'core.mountd.1268185359' of 1877: /usr/lib/nfs/mountd > ----------------- lwp# 1 / thread# 1 -------------------- > feef1687 __pollsys (80e8c28, 8, 0, 0, 0, feb4c000) + 7 > fee97824 poll (80e8c28, 8, ffffffff, feafbbaf) + 4c > feafbd21 _svc_run_mt (feb4da88, feb4da98, feb4daa8, feb4daa8, 8054ba3, > feec8868) + 1bd > feafb7c3 svc_run (1, 2328, 1, 0, 8047e18, feffb7b4) + 77 > 08054ba3 main (1, 8047e5c, 8047e64, feffb7b4) + 4af > 0805457d _start (1, 8047ef8, 0, 8047f0c, 8047f22, 8047f3a) + 7d > ----------------- lwp# 2 / thread# 2 -------------------- > feef1667 __pause (8, 200, 8, 5, fe000, fef7f000) + 7 > 08054677 nfsauth_svc (0, fef7f000, fed5efec, feeecd1e) + 3b > feeecd56 _thrp_setup (fee00a00) + 7e > feeecfe0 _lwp_start (fee00a00, 0, 0, feeecd1e, 0, 0) > ----------------- lwp# 3 / thread# 3 -------------------- > feef1667 __pause (8, 200, 8, 6, fe000, fef7f000) + 7 > 080546d3 cmd_svc (0, fef7f000, fec5ffec, feeecd1e) + 3b > feeecd56 _thrp_setup (fee01200) + 7e > feeecfe0 _lwp_start (fee01200, 0, 0, feeecd1e, 0, 0) > ----------------- lwp# 4 / thread# 4 -------------------- > 080562f1 in_access_list (fe99eadc, 0, 80cdf56, 0) + 69 > 08056cc7 check_client_new (80e79b8, fe99eadc, 0, 1) + d3 > 080583e6 nfsauth_access (fe99ed34, fe99ed20, 44, 1) + 13a > 08058518 nfsauth_func (0, fe99edbc, 44, 0, 0, 805847c) + 9c > feef1ff2 __door_return () + 52 > ----------------- lwp# 5 / thread# 5 -------------------- > feef1fc1 __door_return (0, 0, 0, 0) + 21 > feed8d87 door_create_func (0, fef7f000, fe89ffec, feeecd1e) + 2f > feeecd56 _thrp_setup (fee02200) + 7e > feeecfe0 _lwp_start (fee02200, 0, 0, feeecd1e, 0, 0) > > > I am not sure where to go from here and how to get my problem resolved. Any > help will be greatly appreciated.
I suspect that mountd dumps core when executing code in in_access_list() (as one of the stacks shows). Which nevada build is it? Which options did you use for sharing the zfs filesystem? (grep <exported-file-system> /etc/dfs/sharetab) Also output of '::stack' and '::status' mdb commands on core dump could help. cheers jan
