Re: XFS filesystem claims to be mounted after a disconnect

[Martin Papik <mp6058@gmail.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


> It's called a lazy unmount: "umount -l". It disconnects the 
> filesystem from the namespace, but it still lives on in the kernel 
> until all references to the filesystem go away. Given that the 
> hot-unplug proceedure can call back into the filesystem to sync it
> (once it's been disconnected!) the hot unplug can deadlock on
> filesystem locks that can't be released until the hot-unplug errors
> everything out.
> 
> So you can end up with the system in an unrecoverable state when
> USB unplugs.

And the disconnect from the namespace is what removes it from
/proc/mounts?

By hot unplug, do you mean a user initiated "remove device" or a pull
out of the USB cable? I'm sorry, I don't understand your example.
Would you be kind enough to elaborate?

>>> If xfs encounters an insurmountable error, it will shut down,
>>> and all operations will return EIO or EUCLEAN.  You are right
>>> that there is no errors=* mount option; the behavior is not
>>> configurable on xfs.
>> 
>> IMHO it should be, but since the last email I've glanced at some 
>> mailing lists and understand that there's some reluctance, in the
>> name of not polluting the FS after an error. But at least a R/O
>> remount should be possible, to prevent yanking libraries from
>> under applications (root FS).
> 
> What you see here has nothing to do with XFS's shutdown behaviour. 
> The filesystem is already unmounted, it just can't be destroyed 
> because there are still kernel internal references to it.

How can I detect this situation? I mean I didn't see anything in
/proc/mounts or references to the mount point from /proc/<pid>/*, so I
only managed to correct it (chdir elsewhere) by chance on a hunch.
Would it not be desirable to know that there's a phantom FS referenced
by a number of processes?

Also, do you know if this affects other filesystems? I never saw this
with ext3/4 or reiser, I don't have much practical experience with
other filesystems. I ask because your explanation sounds like it's vfs
rather than xfs, but as I said, I never saw this before.

>>> documentation, that's probably something we should address.
>> 
>> Yup, any idea when? .... Also, I think it would be good to have
>> a section on what to do when things go south and what to expect.
>> E.g. I found out the hard way that xfs_check on a 2TB disk
>> allocates 16G of memory, so now I'm running it with cgroup based
>> limitations, otherwise
> 
> $ man xfs_check .... Note that xfs_check is deprecated and
> scheduled for removal in June 2014. Please use xfs_repair -n
> instead.

Thanks, I didn't know that.

Martin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJTZDKTAAoJELsEaSRwbVYr5T4QAJ+10OjafQUnX6zvG0Lrhs1C
G+4Liuxm5aUmINKfUEeuhPJOsNfrdrSs+/SW6G9u5Lhu6FSrll/+O1BLa4Ld6Mxx
3IADom8RQl0rcEMpBGnPNi1hTY0RycYk+Pzug1GzCz2nDE6zCojobvGoW8a02BaL
pEdfh0NXDVAjSbTubHKXSqxWydIkVJacbshEy/BhySQuZmPSiu1BOIV1DTvGLqIz
VIsYDkv7UvuZyKsBL+0ux/9gPVPNP78hIIvUU9hLomjfnUum02vV6ps6RJZtGjVt
OKZ02qaIjaRPtlFCU21YTFr/x0WIGFsh7Zzfma4sDs4tXCqB7FEs+NA4Fq0zoHV0
OSCiiBgCTTtkph0Bn5/WycoVfkxm9eCru5eCLY1NeBRCIFi5rlRNX/Uvo9YO3twA
PvvGMHFROYtNl0u+/e1Tkniylwtanx7esMgVb0rC4IYHeovxZkHIuFkjHv5/PMNs
p+w8u6ZOfKOARUfYiFHOLVR/QAhp4ubhpTegD7d6Eqqtea/d/vGrUj6Bu/4svZ9j
YsVmYqsnUe1Uisz+NarmH/t7KeeRJBqEPLvJ9rZ2P7ixQLOTxsnuyU7kOdZKpwIM
jHAzaAIfxcntyL76hPbnkAdSZU//zOv3qfyfkD/NuqnKi1BOsQKZMMb9NEcA4OOg
QoWmXdMC64OlWv1Buxdr
=qP6z
-----END PGP SIGNATURE-----

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs