LinuxLists.cc - Detectiong Network and umount / mount NFS

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

[email protected] wrote:
> > I have a portable computer with FC3. This computer have Wireless and =
Wired
> > network and i have some NFS mount points in my file system.
> >
> > Usualy i want to change throught between the wireless and wired conne=
ction
> and
> > when i do this my mount points became busy.
> Try 'lsof /home/Acropole` to see what process is using
> the filesystem.

This system freeze. Don't give any information.....

> >
> > There is some way to umount NFS mount points after the system loose t=
he
> network?
> not safely...

Why? There is no Network!! Why the NFS mantain the connection? Should the=
NFS
umount the mount points?

(())
Esqueleto
Odivelas - Portugal

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime in=
fo,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-21 00:20:16

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

to den 21.04.2005 Klokka 00:00 (+0100) skreiv [email protected]:
> > > There is some way to umount NFS mount points after the system loose the
> > network?
> > not safely...
>
> Why? There is no Network!! Why the NFS mantain the connection? Should the NFS
> umount the mount points?
>

Umm... Perhaps because there is a general consensus among NFS developers
that throwing away people's data, and killing off their processes
without their consent might be a bad thing?

If you want that sort of behaviour, then read all about the "soft" mount
option ("man 5 nfs", and http://nfs.sourceforge.net/#faq_d6).

Cheers,
Trond

--
Trond Myklebust <[email protected]>

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-21 08:15:00

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

On Wed, 20 Apr 2005, Trond Myklebust wrote:

>> Why? There is no Network!! Why the NFS mantain the connection? Should the NFS
>> umount the mount points?
>>
>
> Umm... Perhaps because there is a general consensus among NFS developers
> that throwing away people's data, and killing off their processes
> without their consent might be a bad thing?

The problem is that it's hard to get rid of the mount even if you want.
There is no --force-I-really-want-this.

> If you want that sort of behaviour, then read all about the "soft" mount
> option ("man 5 nfs", and http://nfs.sourceforge.net/#faq_d6).

I think Esqueleto wants a Solaris-type "umount -f". I'd like to have that
too.

Is there any bug in http://bugzilla.kernel.org/ that I can vote for?

--
Peter ?strand Chief Developer
Cendio http://www.thinlinc.com
Teknikringen 3 http://www.cendio.se
583 30 Link?ping Phone: +46-13-21 46 00

2005-04-21 08:21:25

by Rudy Zijlstra

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

Peter =C5strand wrote:

> On Wed, 20 Apr 2005, Trond Myklebust wrote:
>
>>> Why? There is no Network!! Why the NFS mantain the connection?=20
>>> Should the NFS
>>> umount the mount points?
>>>
>>
>> Umm... Perhaps because there is a general consensus among NFS develope=
rs
>> that throwing away people's data, and killing off their processes
>> without their consent might be a bad thing?
>
>
> The problem is that it's hard to get rid of the mount even if you=20
> want. There is no --force-I-really-want-this.

read up on lazy unmount

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime in=
fo,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-21 08:28:30

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

On Thu, 21 Apr 2005, Rudy Zijlstra wrote:

>>> Umm... Perhaps because there is a general consensus among NFS developers
>>> that throwing away people's data, and killing off their processes
>>> without their consent might be a bad thing?
>>
>>
>> The problem is that it's hard to get rid of the mount even if you want.
>> There is no --force-I-really-want-this.
>
> read up on lazy unmount

As I understand it, lazy umounts are not the same thing as forced umounts.
With lazy umounts, the process still hangs. With Solaris-type forced
umounts, the programs will get an error (EIO).

--
Peter ?strand Chief Developer
Cendio http://www.thinlinc.com
Teknikringen 3 http://www.cendio.se
583 30 Link?ping Phone: +46-13-21 46 00

2005-04-21 08:51:44

by Rudy Zijlstra

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

Peter =C5strand wrote:

> On Thu, 21 Apr 2005, Rudy Zijlstra wrote:
>
>>>> Umm... Perhaps because there is a general consensus among NFS=20
>>>> developers
>>>> that throwing away people's data, and killing off their processes
>>>> without their consent might be a bad thing?
>>>
>>>
>>>
>>> The problem is that it's hard to get rid of the mount even if you=20
>>> want. There is no --force-I-really-want-this.
>>
>>
>> read up on lazy unmount
>
>
> As I understand it, lazy umounts are not the same thing as forced=20
> umounts. With lazy umounts, the process still hangs. With Solaris-type=20
> forced umounts, the programs will get an error (EIO).
>
True, it may still solve the problem of the OP.

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime in=
fo,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-21 13:05:35

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

to den 21.04.2005 Klokka 10:14 (+0200) skreiv Peter =C3=85strand:
> > If you want that sort of behaviour, then read all about the "soft" moun=
t
> > option ("man 5 nfs", and http://nfs.sourceforge.net/#faq_d6).
>=20
> I think Esqueleto wants a Solaris-type "umount -f". I'd like to have that=
=20
> too.

You didn't actually read that FAQ entry, that I pointed to, did you?
Please do.

This is not something that will happen soon, unless you or someone else
who feels strongly about it pulls up their sleeves, and starts
developing. Adding bugzilla entries for this type of feature will just
serve to annoy.

--=20
Trond Myklebust <[email protected]>

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-21 13:28:38

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

I don't think that you undestand the problem. I have NFS mount points in =
my
FileSystem and I want to change from Wired and Wireless and don't loose t=
he
mount points.

now, when I change for 1 or 2 seconds there will be no network and the NF=
S does
not resume the connection after the netwoek is up (or is not immediately)=
.
What I want if for the NFS it self umount when the network connection doe=
s not
exists.
If this happen i can mount again when the network is up again.

This problem does not exists in Desktop computers only laptops with wirel=
ess and
wired connection.

(())
Esqueleto
Odivelas - Portugal

Quoting Trond Myklebust <[email protected]>:

> to den 21.04.2005 Klokka 10:14 (+0200) skreiv Peter =C3=85strand:
> > > If you want that sort of behaviour, then read all about the "soft" =
mount
> > > option ("man 5 nfs", and http://nfs.sourceforge.net/#faq_d6).
> >
> > I think Esqueleto wants a Solaris-type "umount -f". I'd like to have =
that
> > too.
>
> You didn't actually read that FAQ entry, that I pointed to, did you?
> Please do.
>
> This is not something that will happen soon, unless you or someone else
> who feels strongly about it pulls up their sleeves, and starts
> developing. Adding bugzilla entries for this type of feature will just
> serve to annoy.
>
> --
> Trond Myklebust <[email protected]>
>
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime in=
fo,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-21 13:50:08

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

to den 21.04.2005 Klokka 14:28 (+0100) skreiv [email protected]:
> now, when I change for 1 or 2 seconds there will be no network and the NFS does
> not resume the connection after the netwoek is up (or is not immediately).
> What I want if for the NFS it self umount when the network connection does not
> exists.
> If this happen i can mount again when the network is up again.

No, you don't appear to understand.

umount requires you to kill all applications that are using a partition.
That is true for ALL filesystems, and is enforced in the VFS. Try
umounting "/" or "/home" while you are logged in.

So, one thing that we are thinking of implementing is a so-called
"disconnected" mode, in which NFS switches over to using local disk when
you disconnect from the network (like AFS is somewhat able to do).
That will enable you to continue working without killing off processes,
but it requires something like cachefs to ensure that your in-use files
are backed by local disk. Don't expect this to be ready anytime in the
near future...

Alternatively, you should look into using something like the
"intermezzo" filesystem. The latter is available on 2.4 kernels (but is
unmaintained and was therefore kicked out of 2.6), and is designed to
work in laptop-like environments.

Cheers,
Trond
--
Trond Myklebust <[email protected]>

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-21 14:04:43

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

Ok

now I undestand what is the problem. May be this will be a big problem (v=
oted in
Bugzilla) and develop this feature fast.

I will wait for this.

tkx

Esqueleto
Odivelas - Portugal

> No, you don't appear to understand.
>
> umount requires you to kill all applications that are using a partition=
.
> That is true for ALL filesystems, and is enforced in the VFS. Try
> umounting "/" or "/home" while you are logged in.
>
> So, one thing that we are thinking of implementing is a so-called
> "disconnected" mode, in which NFS switches over to using local disk whe=
n
> you disconnect from the network (like AFS is somewhat able to do).
> That will enable you to continue working without killing off processes,
> but it requires something like cachefs to ensure that your in-use files
> are backed by local disk. Don't expect this to be ready anytime in the
> near future...
>
> Alternatively, you should look into using something like the
> "intermezzo" filesystem. The latter is available on 2.4 kernels (but is
> unmaintained and was therefore kicked out of 2.6), and is designed to
> work in laptop-like environments.
>
> Cheers,
> Trond
> --
> Trond Myklebust <[email protected]>
>
>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime in=
fo,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-21 19:27:01

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

On Thu, 21 Apr 2005, Trond Myklebust wrote:

> to den 21.04.2005 Klokka 10:14 (+0200) skreiv Peter ?strand:
>>> If you want that sort of behaviour, then read all about the "soft" mount
>>> option ("man 5 nfs", and http://nfs.sourceforge.net/#faq_d6).
>>
>> I think Esqueleto wants a Solaris-type "umount -f". I'd like to have that
>> too.
>
> You didn't actually read that FAQ entry, that I pointed to, did you?
> Please do.

I did not, because I thought it was only about soft mounts. I don't want
soft mounts.

I've read it now, but it didn't make me much wiser. It talks about soft
mounts, which I don't want. It takes about killing processes, which I
don't want to do by hand: I think "umount -f" should suffice. The the
processes itself can decide what to do with the EIO.

> This is not something that will happen soon, unless you or someone else
> who feels strongly about it pulls up their sleeves, and starts
> developing. Adding bugzilla entries for this type of feature will just
> serve to annoy.

I'm patient. I don't understand why people are annoyed by bugzilla
entries, though.

--
Peter ?strand Chief Developer
Cendio http://www.thinlinc.com
Teknikringen 3 http://www.cendio.se
583 30 Link?ping Phone: +46-13-21 46 00

2005-04-21 21:21:06

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

to den 21.04.2005 Klokka 21:26 (+0200) skreiv Peter =C3=85strand:
> On Thu, 21 Apr 2005, Trond Myklebust wrote:
>=20
> > to den 21.04.2005 Klokka 10:14 (+0200) skreiv Peter =C3=85strand:
> >>> If you want that sort of behaviour, then read all about the "soft" mo=
unt
> >>> option ("man 5 nfs", and http://nfs.sourceforge.net/#faq_d6).
> >>
> >> I think Esqueleto wants a Solaris-type "umount -f". I'd like to have t=
hat
> >> too.
> >
> > You didn't actually read that FAQ entry, that I pointed to, did you?
> > Please do.
>=20
> I did not, because I thought it was only about soft mounts. I don't want=20
> soft mounts.
>=20
> I've read it now, but it didn't make me much wiser. It talks about soft=20
> mounts, which I don't want. It takes about killing processes, which I=20
> don't want to do by hand: I think "umount -f" should suffice. The the=20
> processes itself can decide what to do with the EIO.

The kernel already aborts all pending I/O and returns EIO with "umount
-f". That doesn't do anything for those tasks that are not waiting on
I/O, though. Nor will it do anything for those that handle EIOs without
aborting.

Solaris' version of "umount -f" combines the above behaviour with our
"lazy umount". There's nothing stopping you doing that in linux too
("umount -lf"). That still doesn't guarantee that processes will die in
a timely manner, though.

> > This is not something that will happen soon, unless you or someone else=
=20
> > who feels strongly about it pulls up their sleeves, and starts=20
> > developing. Adding bugzilla entries for this type of feature will just=20
> > serve to annoy.
>=20
> I'm patient. I don't understand why people are annoyed by bugzilla=20
> entries, though.

Three reasons:

1) That bugzilla is meant for reporting kernel bugs, not for feature
requests

2) It is rigged to send out periodic mails. Whereas that may be useful
for bugs, it only serves to irritate when it comes to feature requests.

3) There is in any case no provision for "voting" in that bugzilla.
The kernel works on the principle "Whoever wants the feature is free to
implement it at their leisure".

--=20
Trond Myklebust <[email protected]>

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-22 07:12:42

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

On Thu, 21 Apr 2005, Trond Myklebust wrote:

>>> You didn't actually read that FAQ entry, that I pointed to, did you?
>>> Please do.
>>
>> I did not, because I thought it was only about soft mounts. I don't want
>> soft mounts.
>>
>> I've read it now, but it didn't make me much wiser. It talks about soft
>> mounts, which I don't want. It takes about killing processes, which I
>> don't want to do by hand: I think "umount -f" should suffice. The the
>> processes itself can decide what to do with the EIO.
>
> The kernel already aborts all pending I/O and returns EIO with "umount
> -f".

Interesting. How long has this been the case? I've never heard of it
before; i thought that "-f" was only for not careing about the UMNT call.

Perhaps the man-page could say something about this?

A few other interesting things: I've tested this on Fedora. I did a
"strace cat /mnt/foo". The first "umount -f" call gave:

# umount -f /mnt
umount2: Device or resource busy
umount: /mnt: device is busy
umount2: Device or resource busy
umount: /mnt: device is busy

The cat process was still hanged. When doing a second "umount -f",
open("/mnt/foo") returned EIO. This time, the umount command said:

# umount -f /mnt
umount2: Device or resource busy
umount: /mnt: device is bus

One other interesting thing was that then, the kernel crashed... I'm using
kernel 2.6.11-1.14_FC3.

I'm able to reproduce this problem. I have a screen shot of the call trace
on http://www.cendio.se/~peter/fc3-umount-crash.png, if anyone is
interested.

> Three reasons:
>
> 1) That bugzilla is meant for reporting kernel bugs, not for feature
> requests

In my opinion, an "unkillable" process is a bug.

--
Peter ?strand Chief Developer
Cendio http://www.thinlinc.com
Teknikringen 3 http://www.cendio.se
583 30 Link?ping Phone: +46-13-21 46 00

2005-04-22 13:32:10

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

fr den 22.04.2005 Klokka 09:12 (+0200) skreiv Peter =C3=85strand:

> > The kernel already aborts all pending I/O and returns EIO with "umount
> > -f".
>=20
> Interesting. How long has this been the case? I've never heard of it=20
> before; i thought that "-f" was only for not careing about the UMNT call.

Huh? I've never heard anyone say anything about UMNT call behaviour, nor
can I understand where you might have picked that up from the
documentation.
The behaviour of umount and umount -f should be exactly the same: if the
server doesn't respond, the call times out and the return value is
ignored.

> Perhaps the man-page could say something about this?

The manpage says

-f Force unmount (in case of an unreachable NFS system). (Requi=
res
kernel 2.1.116 or later.)

The behaviour of the kernel w.r.t. that flag has been the same since
2.1.116.

> The cat process was still hanged. When doing a second "umount -f",=20
> open("/mnt/foo") returned EIO. This time, the umount command said:
>=20
> # umount -f /mnt
> umount2: Device or resource busy
> umount: /mnt: device is bus
>=20
> One other interesting thing was that then, the kernel crashed... I'm usin=
g=20
> kernel 2.6.11-1.14_FC3.
>=20
> I'm able to reproduce this problem. I have a screen shot of the call trac=
e=20
> on http://www.cendio.se/~peter/fc3-umount-crash.png, if anyone is=20
> interested.

That's certainly an "interesting" Oops. ebp=3D0x1b, esp=3D0xc0446f98,
together with a timer list corruption. Is that running under vmware? If
so, can you reproduce with a normal kernel (no vmware module) and given
that weird value of ebp, with stack overflow checking turned on.

On my machine, the "umount -f" complains a bit about "Cannot MOUNTPROG
RPC (tcp): RPC: Program not registered", and there may be a few "device
is busy" here and there, but the umount definitely succeeds in killing
off the hanging programs, and it fails to Oops.

> > 1) That bugzilla is meant for reporting kernel bugs, not for feature
> > requests
>=20
> In my opinion, an "unkillable" process is a bug.

That's entirely _your_ personal opinion. A lot of other people will
argue that causing processes to lose data is a bug. In order to
accommodate both camps, there are mount options to allow for one or the
other behaviour, there are manpage entries, and there are FAQ entries.

--=20
Trond Myklebust <[email protected]>

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-22 13:43:24

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

> > I'm able to reproduce this problem. I have a screen shot of the call trace
> > on http://www.cendio.se/~peter/fc3-umount-crash.png, if anyone is
> > interested.
>
> That's certainly an "interesting" Oops. ebp=0x1b, esp=0xc0446f98,
> together with a timer list corruption. Is that running under vmware? If
> so, can you reproduce with a normal kernel (no vmware module) and given
> that weird value of ebp, with stack overflow checking turned on.
>
> On my machine, the "umount -f" complains a bit about "Cannot MOUNTPROG
> RPC (tcp): RPC: Program not registered", and there may be a few "device
> is busy" here and there, but the umount definitely succeeds in killing
> off the hanging programs, and it fails to Oops.

Hmm... Moments after I replied, I got this mail on the LKML list.

Could you describe the test you are using to reproduce your Oops in more
detail? How are you causing the network partition?

--
Trond Myklebust <[email protected]>

Attachments:

(No filename) (2.62 kB)
Vedlagt melding - Crash when unmounting NFS/TCP with -f

2005-04-22 13:46:54

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

Quoting Trond Myklebust <[email protected]>:
> > In my opinion, an "unkillable" process is a bug.

It's my opinion too

> That's entirely _your_ personal opinion. A lot of other people will
> argue that causing processes to lose data is a bug. In order to
> accommodate both camps, there are mount options to allow for one or the
> other behaviour, there are manpage entries, and there are FAQ entries.

This is not only an personal opinion ... a process that cannot be killed =
it's
not "well developed".

(())
Esqueleto
Odivelas - Portugal

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=3D6595&alloc_id=3D14396&op=3Dclick
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

2005-04-22 14:25:10

[permalink] [raw]

Subject: Re: Detectiong Network and umount / mount NFS

On Fri, 22 Apr 2005, Trond Myklebust wrote:

>> One other interesting thing was that then, the kernel crashed... I'm using
>> kernel 2.6.11-1.14_FC3.
>>
>> I'm able to reproduce this problem. I have a screen shot of the call trace
>> on http://www.cendio.se/~peter/fc3-umount-crash.png, if anyone is
>> interested.
>
> That's certainly an "interesting" Oops. ebp=0x1b, esp=0xc0446f98,
> together with a timer list corruption. Is that running under vmware?

Yes.

> If so, can you reproduce with a normal kernel (no vmware module) and
> given that weird value of ebp, with stack overflow checking turned on.

Perhaps I'll find time for this, I can't promise anything.

>> In my opinion, an "unkillable" process is a bug.
>
> That's entirely _your_ personal opinion. A lot of other people will
> argue that causing processes to lose data is a bug.

IMHO, if you use "kill -9", you should prepare for losing data (lying in
the process you are killing) anyway, no matter what kind of file systems
are you using.

--
Peter ?strand Chief Developer
Cendio http://www.thinlinc.com
Teknikringen 3 http://www.cendio.se
583 30 Link?ping Phone: +46-13-21 46 00

2005-04-22 14:28:23