nfs + msdosfs = crashes & panics
dillon at apollo.backplane.com
Tue Apr 13 12:33:04 PDT 2004
I don't know whether this is or is not related to Jeff's recent
work and the open bug report from YONETANI Tomokazu. I suspect
that it is not related.
I don't recall us ever supporting anything other then UFS on the
server side. On the otherhand, theoretically, it should be possible
to serve an MSDOSFS partition via NFS, and I would like that support
Go ahead and post a backtrace of the crash that occurs when you try
to write. Also:
* make sure you are using a UDP NFS mount, with no special options.
* make sure the export is read-write (no '-ro' option in the /etc/exports
* make sure that NFS exports of normal UFS filesystems work normally
(do not lock up or crash), which will help us narrow it down to the
probability that it's the MSDOS filesystem that is creating an issue.
Now in regards to the nfsd lockup... if normal UFS filesystems can be
exported just fine and do not lock up, then reproduce the lockup you
are getting with MSDOSFS and try to generate a kernel crash dump.
I'd need the crash dump and the kernel.debug binary associated with the
kernel build you are using. If you can get them, upload them to your
leaf account and email me their location.
Also for the lockup case, a tcpdump of the nfs rpc activity would be useful
to determine whether it is an issue of the client not retrying the request
or of the server not replying to it.
'nfsd' is the normal tsleep message that nfsd is left in when it is
waiting for a request. It's possible that the lockup is related to
Jeff's recent work.
<dillon at xxxxxxxxxxxxx>
:I'm having problems using a NFS-mounted MS-DOS (FAT) partition. This
:may well be because this combination isn't supported, but in case it
:is supposed to be, here are some gory details.
:I have an NFS server running DragonFly. It shares the directory /c to
:the NFS client, which is also running DragonFly. (both are the same
:version, fairly current as of a couple of days ago.)
:The NFS server is dual-boot; ad0 has Windows installed, DragonFly
:resides on ad1. The /c directory, in DragonFly, is a mount of the
:MS-DOS partition on ad0s1. For local usage this is rock-solid.
:Over NFS it does appear to work, at least initially. I can list the
:directories of /c on the client. I can read files under normal usage.
:However, if I try to read a lot of files in quick succession, or really
:big files, the NFS server just locks up. The message on the client is:
: nfs server catbus:/c: not responding
:And on the server, I can see via top that the nfsd process is stuck in
:the state 'nfsd'. I can kill nfsd, but trying to do anything else on
:the client after this point is pretty much impossible; it requires a
:Also, if I try to write a file to the /c share from the client, the
:server's kernel panics. This in general leads me to believe that the
:combination is just not supported (much like write-through unionfs et al
:aren't supported...) but if other people can normally get this to work
:(under other BSD's...?) I'll happily post a backtrace.
More information about the Bugs