umount -a -f -t nfs doesn't work when a file has been written and "-l" option is needed

umount -a -f -t nfs doesn't work when a file has been written and "-l" option is needed

[Pacho Ramos]

I suffer the following problem with nfs since a lot of time, now, I am
using nfs-utils-1.2.0, but older versions were affected too.

When I write a file on a mounted nfs filesystem and server goes down, I
am unable to umount it even with "-f" option, it simply hangs. On the
other hand, if no file was written (for example, it was simply read)
there is no problem and "umount -f" works as expected.

Seems that I need to run "umount -l" for being able to unmount it, even
when I expected that "-f" should be enough.

Is this the proper behavior or something is going wrong?

Thanks a lot :-)

 

umount -a -f -t nfs doesn't work when a file has been written and "-l" option is needed

[Pacho Ramos]

I suffer the following problem with nfs since a lot of time, now, I am
using nfs-utils-1.2.0, but older versions were affected too.

When I write a file on a mounted nfs filesystem and server goes down, I
am unable to umount it even with "-f" option, it simply hangs. On the
other hand, if no file was written (for example, it was simply read)
there is no problem and "umount -f" works as expected.

Seems that I need to run "umount -l" for being able to unmount it, even
when I expected that "-f" should be enough.

Is this the proper behavior or something is going wrong?

Thanks a lot :-)

Re: umount -a -f -t nfs doesn't work when a file has been written and "-l" option is needed

[Steve Dickson]

On 09/05/2009 04:31 AM, Pacho Ramos wrote:
> I suffer the following problem with nfs since a lot of time, now, I am
> using nfs-utils-1.2.0, but older versions were affected too.
> 
> When I write a file on a mounted nfs filesystem and server goes down, I
> am unable to umount it even with "-f" option, it simply hangs. On the
> other hand, if no file was written (for example, it was simply read)
> there is no problem and "umount -f" works as expected.
I believe 'umount -f' waits for all the async or sync (I can't remember)
RPC tasks to complete before returning... That's the reason for the hang.

> 
> Seems that I need to run "umount -l" for being able to unmount it, even
> when I expected that "-f" should be enough.
Hopefully you will be rebooting soon since kernel structures (ala the
super block) are not cleaned up with 'umount -l'. Which could make the
system somewhat unstable. 

> 
> Is this the proper behavior or something is going wrong?
Its the known behaviour... whether its correct or not is up to
interpretation... ;-) Meaning, 'umount -f' probably should
not hang waiting for I/O to finish, but error-ing on the "lets 
do everything we can not to corrupt data" is not a bad stand either...

steved.

Re: umount -a -f -t nfs doesn't work when a file has been written and "-l" option is needed

[Pacho Ramos]

El mar, 08-09-2009 a las 09:40 -0400, Steve Dickson escribi=C3=B3:
> On 09/05/2009 04:31 AM, Pacho Ramos wrote:
> > I suffer the following problem with nfs since a lot of time, now, I=
 am
> > using nfs-utils-1.2.0, but older versions were affected too.
> >=20
> > When I write a file on a mounted nfs filesystem and server goes dow=
n, I
> > am unable to umount it even with "-f" option, it simply hangs. On t=
he
> > other hand, if no file was written (for example, it was simply read=
)
> > there is no problem and "umount -f" works as expected.
> I believe 'umount -f' waits for all the async or sync (I can't rememb=
er)
> RPC tasks to complete before returning... That's the reason for the h=
ang.
>=20
> >=20
> > Seems that I need to run "umount -l" for being able to unmount it, =
even
> > when I expected that "-f" should be enough.
> Hopefully you will be rebooting soon since kernel structures (ala the
> super block) are not cleaned up with 'umount -l'. Which could make th=
e
> system somewhat unstable.=20
>=20
> >=20
> > Is this the proper behavior or something is going wrong?
> Its the known behaviour... whether its correct or not is up to
> interpretation... ;-) Meaning, 'umount -f' probably should
> not hang waiting for I/O to finish, but error-ing on the "lets=20
> do everything we can not to corrupt data" is not a bad stand either..=
=2E
>=20
> steved.
>=20

Thanks a lot for the info :-)

Re: umount -a -f -t nfs doesn't work when a file has been written and "-l" option is needed

[Al Viro]

On Tue, Sep 08, 2009 at 09:40:31AM -0400, Steve Dickson wrote:
> On 09/05/2009 04:31 AM, Pacho Ramos wrote:
> > I suffer the following problem with nfs since a lot of time, now, I am
> > using nfs-utils-1.2.0, but older versions were affected too.
> > 
> > When I write a file on a mounted nfs filesystem and server goes down, I
> > am unable to umount it even with "-f" option, it simply hangs. On the
> > other hand, if no file was written (for example, it was simply read)
> > there is no problem and "umount -f" works as expected.
> I believe 'umount -f' waits for all the async or sync (I can't remember)
> RPC tasks to complete before returning... That's the reason for the hang.
> 
> > 
> > Seems that I need to run "umount -l" for being able to unmount it, even
> > when I expected that "-f" should be enough.
> Hopefully you will be rebooting soon since kernel structures (ala the
> super block) are not cleaned up with 'umount -l'. Which could make the
> system somewhat unstable. 

Um...  Not really.  The damn thing is detached from the namespace and
left alone until it's not busy anymore.  At that point it's hit with the
rest of umount() (i.e. with filesystem driver being told to shut it down).

So it won't go away in that case, but you shouldn't get any instability from
that - from the VFS POV nothing nasty has happened, from the NFS client
code POV... well, it's not being unmounted yet, as far as NFS code cares.
Just a mounted fs from a stuck server...

Re: umount -a -f -t nfs doesn't work when a file has been written and "-l" option is needed

[Pacho Ramos]

El s=C3=A1b, 12-09-2009 a las 16:01 +0100, Al Viro escribi=C3=B3:
> > > Seems that I need to run "umount -l" for being able to unmount it=
, even
> > > when I expected that "-f" should be enough.
> > Hopefully you will be rebooting soon since kernel structures (ala t=
he
> > super block) are not cleaned up with 'umount -l'. Which could make =
the
> > system somewhat unstable.=20
>=20
> Um...  Not really.  The damn thing is detached from the namespace and
> left alone until it's not busy anymore.  At that point it's hit with =
the
> rest of umount() (i.e. with filesystem driver being told to shut it d=
own).
>=20
> So it won't go away in that case, but you shouldn't get any instabili=
ty from
> that - from the VFS POV nothing nasty has happened, from the NFS clie=
nt
> code POV... well, it's not being unmounted yet, as far as NFS code ca=
res.
> Just a mounted fs from a stuck server...

OK :-)

Anyway, I am running this just before halting system , to prevent
suffering the hang when powering off my computer ;-)

Thanks!