All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ragnar Kjørstad" <xfs@ragnark.vestdata.no>
To: "Christian, Chip" <chip.christian@storageapps.com>
Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: Busy inodes after umount
Date: Fri, 20 Jul 2001 01:53:43 +0200	[thread overview]
Message-ID: <20010720015343.B11236@vestdata.no> (raw)
In-Reply-To: <23D04BDBA646D411BDDD00D0B774B53902963BE8@SA-BWMAIL1>
In-Reply-To: <23D04BDBA646D411BDDD00D0B774B53902963BE8@SA-BWMAIL1>; from Christian, Chip on Thu, Jul 19, 2001 at 04:22:07PM -0400

On Thu, Jul 19, 2001 at 04:22:07PM -0400, Christian, Chip wrote:
> I found the same thing happening.  Tracked it down in our case to using fdisk to re-read disk size before mounting.  Replaced it with "blockdev --readpt" and the problem seems to have gone away.  YMMV.

I've now been able to reproduce:

* make a filesystem
* mount it
* export it (nfs)
* mount on remote machine
* lock file (fcntl)
* unexport
* unmount

Then you get the VFS message about self-destruct. Tested with both ext2
and xfs.

The lock is still present in /proc/locks after the umount.

With ext2 I can remount the filesystem successfully, but with XFS I get
the message about duplicate UUIDs and the mount failes. I believe this is a totally 
different problem from the one you were experiencing. (and blockdev doesn't help for me)

I suppose this is a generic kernel bug? 



-- 
Ragnar Kjorstad
Big Storage


> [root@ha2 /root]# mkfs -t xfs -f /dev/sdb1
> meta-data=/dev/sdb1              isize=256    agcount=51, agsize=262144
> blks
> data     =                       bsize=4096   blocks=13305828,
> imaxpct=25
>          =                       sunit=0      swidth=0 blks, unwritten=0
> naming   =version 2              bsize=4096  
> log      =internal log           bsize=4096   blocks=1624
> realtime =none                   extsz=65536  blocks=0, rtextents=0
> [root@ha2 /root]# mount -t xfs /dev/sdb1 /mnt/raid/
> [root@ha2 /root]# umount /mnt/raid/
> [root@ha2 /root]# mount -t xfs /dev/sdb1 /mnt/raid/
> mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
>        or too many mounted file systems
> 
> 
> >From /var/log/messages:
> Jul 19 12:27:15 ha2 kernel: Start mounting filesystem: sd(8,17)
> Jul 19 12:27:16 ha2 kernel: Ending clean XFS mount for filesystem: sd(8,17)
> Jul 19 12:27:19 ha2 kernel: XFS unmount got error 16
> Jul 19 12:27:19 ha2 kernel: linvfs_put_super: vfsp/0xc2ff71e0 left dangling!
> Jul 19 12:27:19 ha2 kernel: VFS: Busy inodes after unmount.  Self-destruct in 5 seconds.  Have a nice day...
> Jul 19 12:27:21 ha2 kernel: XFS: Filesystem has duplicate UUID - can't mount
> 
> 
> This happens on a shared storage cluster with two nodes. The same thing
> happens on both nodes. (I'm only using the device from one device at the
> time)
> 
> linux-2.4.5 with XFS patch from 06112001.
> 
> After a reboot it works again, and I have not been able to reproduce
> yet. It first happened when I was testing NFS locks, so it could be
> related to that.
> 
> 
> 
> -- 
> Ragnar Kjorstad
> Big Storage

       reply	other threads:[~2001-07-19 23:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <23D04BDBA646D411BDDD00D0B774B53902963BE8@SA-BWMAIL1>
2001-07-19 23:53 ` Ragnar Kjørstad [this message]
2001-07-19 23:58   ` Busy inodes after umount Matthew Jacob
2001-07-20  0:38     ` Tad Dolphay
2001-07-20  0:49       ` Ragnar Kjørstad
2001-07-31  0:15       ` Ragnar Kjørstad
2001-08-01  8:18         ` Tony Gale
2001-08-01 18:05           ` Ragnar Kjørstad
2001-08-01 18:30             ` Steve Lord
2001-08-02 11:34         ` Neil Brown

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=20010720015343.B11236@vestdata.no \
    --to=xfs@ragnark.vestdata.no \
    --cc=chip.christian@storageapps.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.