[Top] [All Lists]

Re: XFS filesystem claims to be mounted after a disconnect

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS filesystem claims to be mounted after a disconnect
From: Martin Papik <mp6058@xxxxxxxxx>
Date: Sat, 03 May 2014 03:04:48 +0300
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=55jLAU9QFAjtlaAmTAKg3eojcn44kfRmWZ1no1vu9yA=; b=jW6Jg9OGwaoJl+MMX93zqmQzA/gYDpE/J6B3pzGua7Yogtj0b6d0CQhm91996KUOoX 0HQ6BvQOb2cJay3il6eUsPjUZZTjhBg14XCF9HDDOJByruqQ3S+o3WwxLGv7BV4796zq 0CoWASmhgdzzanIBlRlZLkcpQA6xjkljggrkm6+W6CMdtUiSRhlc6VB90P+P8nXQR8+/ RLG69OXjbSxZcdsSyn8Yp1UkY/uIPOgBSqnpr+OHqCXNZBX941KcIhQqJ6cWBXfa5cgy U2CMluF+4xfzvMOCaRfCrzjhIQOHFJTW4r4cBSS7Le15ZHob920igpe0aTexpVigowbr oi5A==
In-reply-to: <20140502233512.GE26353@dastard>
References: <5363A1D8.2020402@xxxxxxxxx> <5363B4C9.4000900@xxxxxxxxxxx> <5363CB5E.3090008@xxxxxxxxx> <5363CD70.3000006@xxxxxxxxxxx> <5363DBD7.4060002@xxxxxxxxx> <5363E65C.6010006@xxxxxxxxxxx> <5363ECE8.6030706@xxxxxxxxx> <20140502233512.GE26353@dastard>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
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

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.

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


<Prev in Thread] Current Thread [Next in Thread>