Detectiong Network and umount / mount NFS

Detectiong Network and umount / mount NFS

[esqueleto]

Hello

I'm new at NFS malling list and hope this problem was not inserted before=
.

I have a portable computer with FC3. This computer have Wireless and Wire=
d
network and i have some NFS mount points in my file system.

Usualy i want to change throught between the wireless and wired connectio=
n and
when i do this my mount points became busy.

Ex:
$ sudo umount /home/Acropole/
umount: /home/Acropole: device is busy
umount: /home/Acropole: device is busy

There is some way to umount NFS mount points after the system loose the n=
etwork?

tkx in advance
Esqueleto
Odivelas - Portugal



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

----- End forwarded message -----




----------------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[Steve Dickson]

esqueleto@tusofona.com 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 connection and
> when i do this my mount points became busy.
Try 'lsof /home/Acropole` to see what process is using
the filesystem.

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

steved.


-------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[esqueleto]

esqueleto@tusofona.com 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[Trond Myklebust]

to den 21.04.2005 Klokka 00:00 (+0100) skreiv esqueleto@tusofona.com:
> > > 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 <trond.myklebust@fys.uio.no>



-------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 918 bytes --]

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			www.thinlinc.com
Teknikringen 3		www.cendio.se
583 30 Linköping        Phone: +46-13-21 46 00

Re: Detectiong Network and umount / mount NFS

[Rudy Zijlstra]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 745 bytes --]

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			www.thinlinc.com
Teknikringen 3		www.cendio.se
583 30 Linköping        Phone: +46-13-21 46 00

Re: Detectiong Network and umount / mount NFS

[Rudy Zijlstra]

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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[Trond Myklebust]

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 <trond.myklebust@fys.uio.no>



-------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[esqueleto]

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 <trond.myklebust@fys.uio.no>:

> 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 <trond.myklebust@fys.uio.no>
>
>




----------------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[Trond Myklebust]

to den 21.04.2005 Klokka 14:28 (+0100) skreiv esqueleto@tusofona.com:
> 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 <trond.myklebust@fys.uio.no>



-------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[esqueleto]

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 <trond.myklebust@fys.uio.no>
>
>




----------------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1276 bytes --]

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			www.thinlinc.com
Teknikringen 3		www.cendio.se
583 30 Linköping        Phone: +46-13-21 46 00

Re: Detectiong Network and umount / mount NFS

[Trond Myklebust]

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 <trond.myklebust@fys.uio.no>



-------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1879 bytes --]

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			www.thinlinc.com
Teknikringen 3		www.cendio.se
583 30 Linköping        Phone: +46-13-21 46 00

Re: Detectiong Network and umount / mount NFS

[Trond Myklebust]

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 <trond.myklebust@fys.uio.no>



-------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[Trond Myklebust]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]


> > 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 <trond.myklebust@fys.uio.no>

[-- Attachment #2: Vedlagt melding - Crash when unmounting NFS/TCP with -f --]
[-- Type: message/rfc822, Size: 2686 bytes --]

From: Brice Goglin <Brice.Goglin@ens-lyon.org>
To: trond.myklebust@fys.uio.no
Cc: linux-kernel@vger.kernel.org
Subject: Crash when unmounting NFS/TCP with -f
Date: Fri, 22 Apr 2005 14:32:09 +0200
Message-ID: <4268EEC9.8010305@ens-lyon.org>

Hi Trond,

I'm using NFS (v2) over TCP (in a SSH tunnel).
Each time the SSH dies before a umount NFS, I have to umount -f
and I get a crash (only sysrq works).
Actually, the crash occurs a few seconds after umount -f.

It seems that killing SSH by hand does _not_ lead to crash.
But a long network failure does.
I remember seeing this bug several times with all stable releases
from 2.6.7 to 2.6.11. I didn't try with earlier versions.

I didn't see anything in the logs (after reboot). But I can't be sure
there was nothing in dmesg since I didn't get a chance to chvt 1 and
see console messages before rebooting (with sysrq).

Do you have any idea how to debug this ?

Thanks,
Brice

Re: Detectiong Network and umount / mount NFS

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1211 bytes --]

On Fri, 22 Apr 2005, Trond Myklebust wrote:

>>> 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.

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

I'm using FC3 as both host and guest OS. The host OS is running the NFS 
server. My exports file looks like:

/mp3             *

There's only one single file below /mp3: /mp3/foo. The network stays up 
all the time, but I did "service nfs stop" on the host before doing 
"strace cat /mnt/foo" in the guest OS.

(I'm away over the weekend, but I will be back on monday. Have a nice 
weekend, all of you.)

Regards,
-- 
Peter Åstrand		Chief Developer
Cendio			www.thinlinc.com
Teknikringen 3		www.cendio.se
583 30 Linköping        Phone: +46-13-21 46 00

Re: Detectiong Network and umount / mount NFS

[esqueleto]

Quoting Trond Myklebust <trond.myklebust@fys.uio.no>:
> > 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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Detectiong Network and umount / mount NFS

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1185 bytes --]

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			www.thinlinc.com
Teknikringen 3		www.cendio.se
583 30 Linköping        Phone: +46-13-21 46 00