Linux NFS development
 help / color / mirror / Atom feed
From: Frank Steiner <fsteiner-mail1@bio.ifi.lmu.de>
To: nfs@lists.sourceforge.net, linux-lvm@redhat.com
Subject: Stale NFS handles on LVM2
Date: Wed, 30 May 2007 09:07:10 +0200	[thread overview]
Message-ID: <465D229E.5080809@bio.ifi.lmu.de> (raw)

Hi,

I'm not sure if this is a NFS or LVM issue, so I cross-post this.
We get stale NFS handles on a LVM2 volume in the following scenario:

- The NFS server is running SLES10/kernel 2.6.16, but it happens
  with 2.6.21, too

- the server has /dev/sda, a built-in SCSI disk, with
  /dev/sda7 a LVM2 volume, say "exportlvm"

- due to module order in the initrd sda is always sda

- exportlvm is exported to the NFS clients

- the server has 4 fibre-channel raids connected, those have
  several partitions and two of the raids have LVM2 filesystems.

- the server doesn't mount or export any of the FC filesystems

Now, when we shutdown the fc port of the server or remove the fc cable, so 
that all the fc filesystems disappear, and then reboot the server,
the NFS client gets stale NFS handles on the "exportlvm". When we reboot
the client and then reconnect the FC cable or port and reboot the server
again, the stale NFS handles show up again.

When we change /dev/sda7 from a LVM2 to a normal fs, there are no stale 
NFS handles when rebooting the server in this way. 

Looks like rebooting the server after dis-/connecting the FC raids with
their LVMs somehow changes sth. on the LVM2 on /dev/sda7, like the minor
numbers etc. Is that possible? Is it a bug? Indeed the "exportlvm" is 
the last in the list when calling "vgscan" with the FC raids connected.

Is there a way I can ensure that things like minor numbers (or whatever
could cause these stales) are persistent on the "exportlvm"?

cu,
Frank
-- 
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik    Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17           Phone: +49 89 2180-4049
80333 Muenchen, Germany       Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

             reply	other threads:[~2007-05-30  7:07 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-30  7:07 Frank Steiner [this message]
2007-05-30  8:23 ` Stale NFS handles on LVM2 Frank van Maarseveen
2007-05-30 12:28   ` Jeff Layton
2007-06-01  9:35   ` Frank Steiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=465D229E.5080809@bio.ifi.lmu.de \
    --to=fsteiner-mail1@bio.ifi.lmu.de \
    --cc=linux-lvm@redhat.com \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox