-----BEGIN PGP SIGNED MESSAGE-----
> 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
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
Thanks, I didn't know that.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----