-----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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
