Hello,
I have not tracked down as to the exact reason,
but it appears umount of v4 file system cause the
directory to be revalidating causing the GETATTR.
Is this revalidation really necessary on an unmount?
tia,
steved.
On 15/02/13 13:25, J. Bruce Fields wrote:
> On Fri, Feb 15, 2013 at 10:46:00AM -0500, Steve Dickson wrote:
>> Hello,
>>
>> I have not tracked down as to the exact reason,
>> but it appears umount of v4 file system cause the
>> directory to be revalidating causing the GETATTR.
>>
>> Is this revalidation really necessary on an unmount?
>
> I don't know, maybe not. But even if it's not, there are other things
> (like cleaning up state) that the client will likely try to do on
> unmount. In the presence of delegations it could have dirty data that
> it's required to write back even if applications don't currently hold
> any open files.
Understood with dirty data... but what I as seeing was a v4 mount and
then a reboot with no activity on the mount point...
>
> So I don't think we can promise umount will work without the network.
Again with open files (aka activity on the mount point) I agree but
with no activity or open files, I'm think that GETATTR is simply not
necessary...
steved.
On Fri, Feb 15, 2013 at 10:46:00AM -0500, Steve Dickson wrote:
> Hello,
>
> I have not tracked down as to the exact reason,
> but it appears umount of v4 file system cause the
> directory to be revalidating causing the GETATTR.
>
> Is this revalidation really necessary on an unmount?
I don't know, maybe not. But even if it's not, there are other things
(like cleaning up state) that the client will likely try to do on
unmount. In the presence of delegations it could have dirty data that
it's required to write back even if applications don't currently hold
any open files.
So I don't think we can promise umount will work without the network.
--b.
On 16/02/13 00:17, Myklebust, Trond wrote:
>> -----Original Message-----
>> From: [email protected] [mailto:linux-nfs-
>> [email protected]] On Behalf Of Steve Dickson
>> Sent: Friday, February 15, 2013 4:46 PM
>> To: J. Bruce Fields
>> Cc: [email protected]
>> Subject: Re: V4 unmount causes a GETATTR
>>
>>
>>
>> On 15/02/13 13:25, J. Bruce Fields wrote:
>>> On Fri, Feb 15, 2013 at 10:46:00AM -0500, Steve Dickson wrote:
>>>> Hello,
>>>>
>>>> I have not tracked down as to the exact reason, but it appears umount
>>>> of v4 file system cause the directory to be revalidating causing the
>>>> GETATTR.
>>>>
>>>> Is this revalidation really necessary on an unmount?
>>>
>>> I don't know, maybe not. But even if it's not, there are other things
>>> (like cleaning up state) that the client will likely try to do on
>>> unmount. In the presence of delegations it could have dirty data that
>>> it's required to write back even if applications don't currently hold
>>> any open files.
>> Understood with dirty data... but what I as seeing was a v4 mount and then a
>> reboot with no activity on the mount point...
>>
>>>
>>> So I don't think we can promise umount will work without the network.
>> Again with open files (aka activity on the mount point) I agree but with no
>> activity or open files, I'm think that GETATTR is simply not necessary...
>
> You'd need to add a lookup intent specifically for umount. Otherwise the filesystem will not be able distinguish between path lookups for umount and other activity.
>
> Also note that "no activity or open files" is no guarantee that you won't be holding delegations or pNFS layouts to return; you may still see hangs.
>
I've also noticed force mounts this clean up does not happen (aka the GETATTR is not sent)... which is the price of doing forced mounts...
steved.
> -----Original Message-----
> From: [email protected] [mailto:linux-nfs-
> [email protected]] On Behalf Of Steve Dickson
> Sent: Friday, February 15, 2013 4:46 PM
> To: J. Bruce Fields
> Cc: [email protected]
> Subject: Re: V4 unmount causes a GETATTR
>
>
>
> On 15/02/13 13:25, J. Bruce Fields wrote:
> > On Fri, Feb 15, 2013 at 10:46:00AM -0500, Steve Dickson wrote:
> >> Hello,
> >>
> >> I have not tracked down as to the exact reason, but it appears umount
> >> of v4 file system cause the directory to be revalidating causing the
> >> GETATTR.
> >>
> >> Is this revalidation really necessary on an unmount?
> >
> > I don't know, maybe not. But even if it's not, there are other things
> > (like cleaning up state) that the client will likely try to do on
> > unmount. In the presence of delegations it could have dirty data that
> > it's required to write back even if applications don't currently hold
> > any open files.
> Understood with dirty data... but what I as seeing was a v4 mount and then a
> reboot with no activity on the mount point...
>
> >
> > So I don't think we can promise umount will work without the network.
> Again with open files (aka activity on the mount point) I agree but with no
> activity or open files, I'm think that GETATTR is simply not necessary...
You'd need to add a lookup intent specifically for umount. Otherwise the filesystem will not be able distinguish between path lookups for umount and other activity.
Also note that "no activity or open files" is no guarantee that you won't be holding delegations or pNFS layouts to return; you may still see hangs.
Cheers,
Trond