DragonFly BSD
DragonFly bugs List (threaded) for 2004-04
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: nfs + msdosfs = crashes & panics

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 13 Apr 2004 12:32:02 -0700 (PDT)

    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
    to work.

    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.

					Matthew Dillon 

: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
:power cycle.
: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.

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]