Re: Problem using exportfs in an active-active nfs cluster

Neil Brown
2010-06-10T04:09:17Z

On Wed, 09 Jun 2010 12:28:43 +0200
RaSca <rasca@miamammausalinux.org> wrote:

> Il giorno Mer 09 Giu 2010 10:04:39 CET, Neil Brown ha scritto:
> [...]
> > Seems unlikely ... "exportfs -f" flushes all the export caches in the kernel
> > thus letting go of any filesystems.
> > I guess an active NFS request could still hold the fs active, but that should
> > complete fairly quickly.
> > file locking might be an issue. Might a client have a lock on some file in
> > the filesystem? Failover of locks is rather more complicated that simple
> > file-access fail-over. I don't recall what the status of this is currently.
> > When the umount files, check the content of
> > /proc/net/rpc/nfsd.export/content
> > and
> > /proc/locks
> > to check what is actually using the filesystem.
>
> Note that I'm mounting from the client with nolock option.
>
> Here is the output of the two cat:
>
> /proc/net/rpc/nfsd.export/content:
>
> #path domain(flags)#012#
> /share-a#011192.168.1.0/24(rw,no_root_squash,sync,wdelay,crossmnt,no_subtree_check,fsid=1,uuid=7c80c4af:2a244b39:af
> adb554:8c8e0574)
>
> /proc/locks:
>
> 1: POSIX ADVISORY WRITE 753 00:11:3923 0 EOF#0122: FLOCK ADVISORY
> WRITE 739 00:11:3916 0 EOF#0123: POSIX ADVISORY WRITE 522 00:11:3049
> 0 EOF
>
> What do you think about it?
>

Clearly there are no locks .. though I wonder what is mounted on 00:11.
Probably not important.

The fact that the export entry is there after you did "exportfs -f" strong
suggests that a new request came in and caused mountd to re-add the entry.

Do you disable the network interface that the clients connect to *before*
unexporting? If you don't, you should.
Maybe run mountd with "-d all" and see what it is doing when you are
unexporting and unmounting.

NeilBrown