For what it's worth, would second this approach of using a flag to unexport and associating the cleanup with that. Another quick hack we used was to store the NSM entries on a standard location on the respective exported filesystem, so that notification is sent once the filesystem comes back online on the destination server and is exported again. BTW, this was not on Linux. It was a simple solution providing the necessary active/active and active/passive cluster support. - Madhan >>> On 6/12/2006 at 9:14:55 pm, in message <448D8BF7.7010105@xxxxxxxxxx>, Wendy Cheng <wcheng@xxxxxxxxxx> wrote: > J. Bruce Fields wrote: > >>On Mon, Jun 12, 2006 at 01:25:43AM -0400, Wendy Cheng wrote: >> >> >>>2. Adding a new flag into "exportfs" command, say "h", such that >>> >>> "exportfs -uh *:/export_path" >>> >>>would un-export the entry and drop the NLM locks associated with the >>>entry. >>> >>> >> >>What does the kernel interface end up looking like in that case? >> >> >> > Happy to see this new exportfs command gets positive response - it was > our original pick too. > > Uploaded is part of a draft version of 2.4 base kernel patch - we're > cleaning up 2.6 patches at this moment. It basically adds a new export > flag (NFSEXP_FOLOCK - note that ex_flags is an int but is currently only > defined up to 16 bits) so nfs-util and kernel can communicate. > > The nice thing about this approach is the recovery part - the take-over > server can use the counter part command to export and set grace period > for one particular interface within the same system call. > > -- Wendy -- Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
