Re: 'umount -f /mnt/foo' fails if server IP is gone.

[Ben Greear <greearb@candelatech.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-7, Size: 1614 bytes --]

On 10/17/2013 11:32 AM, Myklebust, Trond wrote:
> On Thu, 2013-10-17 at 11:11 -0700, Ben Greear wrote:
>> On 10/17/2013 11:05 AM, Myklebust, Trond wrote:
>>> On Thu, 2013-10-17 at 10:35 -0700, Ben Greear wrote:
>>>> On 10/15/2013 11:29 AM, Ben Greear wrote:
>>>>> Is 'umount -f' supposed to always work, even if the file server
>>>>> goes away?
>>>>>
>>>>> I have a user's system that just hangs forever in this case.
>>>>>
>>>>> Could be local changes we have made, but I'm curious about
>>>>> the expected behaviour before I go digging too deep...
>>>>
>>>> Any input on this?  I don't mind trying to fix it, but I
>>>> would like to know how it is supposed to work.
>>>
>>> 'umount -f' has always been iffy. It just kills any pending RPC calls
>>> _before_ trying to unmount. Since the unmount itself can trigger
>>> writeback flushes (and hence more RPC calls), the trace you are seeing
>>> is indeed possible.
>>
>> I tried 'umount -f -l', and that also does not work.
>>
>> Any ideas on how to fix this properly?
> 
> 'umount -f -l' should normally work to at least hide the gruesome
> details of your hanging superblock.
> 
> I'm guessing that you're falling afoul of the path revalidation that
> Chuck alluded to. There should already be a fix for that problem with
> the path_umountat() patches that went into Linux 3.12-rc1. Are those
> failing to help?

I have not tried past 3.9.11+ kernel yet.  I will go look for those patches
you mention as well.  Did any of this go to -stable by chance?

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com