Since I malformed the address this didn't make it to the list:
>
>
> Danny writes:
> => All,
> => Mar 29 03:19:15 dsc_proto_1 kernel: XFS unmount got error 38
> => Mar 29 03:19:15 dsc_proto_1 kernel: linvfs_put_super: vfsp/0xc3bc2ae0
> => left dangling!
> => Mar 29 03:19:15 dsc_proto_1 kernel: VFS: Busy inodes after unmount.
> => Self-destruct in 5 seconds. Have a nice day...
> => Mar 29 03:19:56 dsc_proto_1 kernel: XFS: Filesystem has duplicate UUID -
> => can't mount
>
> => Now: I'm pretty sure that a reboot would allow the mount to succeed; in
> => other words, /dev/md1 is still "mounted" in some way in the kernel;
> => hence the dup UUID.
>
> If xfs_unmountfs doesn't get called, the uuid for the mounted xfs fs won't
> get removed from the uuid table, and further mounts of that filesystem
> will be rejected. There are a couple of paths in which the unmount can
> fail to call xfs_unmountfs, but they shouldn't happen unless something
> is really wrong anyway.
>
> What I'm really curious about is why the unmount failed in the first
> place - that definitely shouldn't be happening.
>
Curious, I just hit this running a forced shutdown test. Different
error, same effect. In my case, it definitely won't follow the code
path to call xfs_unmountfs(). In either event, it doesn't look like
the filesystem is mounted in any useful sense.
I am curious to know how it got here. Any information would be
appreciated.
> Can you give us some vitals on your setup? Are you using highmem, quota,
> acls, dmapi etc? Running any specific tests?
>
> => This machine is a test machine only. Is there anything you'd like me
> => to try before I reboot?
>
> I think it's too late now. If you can work out how to repeat this problem,
> we should be able to suggest some ways to debug it.
>
If I read the code right, there isn't much else which can be done besides
rebooting.....
Mark
|