> Message: 1
> From: "Cole, Timothy D." <[email protected]>
> To: 'Scott Mcdermott' <[email protected]>, =
[email protected]
> Subject: RE: [NFS] Re: broken umount -f
> Date: Wed, 15 Jan 2003 10:46:42 -0800
>=20
> > -----Original Message-----
> > From: Scott Mcdermott [mailto:[email protected]]
> > Sent: Wednesday, January 15, 2003 12:24
> > To: [email protected]
> > Subject: Re: [NFS] Re: broken umount -f
> >=20
> > User saving his mail spool, sees "nfs server not responding, still
> > trying" and decides to try killing his MUA. Too bad it works and =
now
> > his spool is a steaming pile of ASCII.
>=20
> That's possible with non-NFS filesystems too -- just normally a =
smaller
> window of opportunity. It doesn't require a filesystem hang in any =
case --
> most mailbox operations are not a single atomic write(). Imagine =
someone
> killing the MUA in the middle of deleting a large mail from a ~40MB =
mail
> spool on any filesystem, local or remote.
>=20
> Also consider the nointr case -- process hangs, user can't kill it, =
user
> naively closes the terminal window. Server comes back up. SIGHUP is
> finally handled when the write() returns. Process dies. ASCII soup =
again.
>=20
> This is of course assuming that the NFS server _can_ come back up. If =
not,
> totally unkillable processes are a pain-in-the-ssh.
>=20
> > `soft' and `intr' are evil and should be banned.
>=20
> Agreed WRT soft's evil-ness, anyway. But hard,intr seems to be a =
pretty
> good combination, as far as safety from data corruption, and from a
> standpoint of not having to reboot-and-kill-week-long-simulations just
> because a few unrelated (but important) processes got wedged by a
> recalcitrant NFS server.
>=20
Thinking about it, having non-intr won't save you in any way shape for
form.
If the nfs server pauses for some reason and you have non-intr and the=20
user hits ctrl-c or something similir, it will just wait for the server =
to come
back and then take the ctrl-c and abruptly kill the program, if the=20
operation(s) takes any amount of time you will still have corrupted =
files.
Roger
-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Heflin, Roger A. on Wed 15/01 13:59 -0600:
> Thinking about it, having non-intr won't save you in any way shape for
> form.
although I tried, I can't think of a case where this is wrong. I'll
just remount my filesystems with `intr'. But, I still think that with
`intr', umount -f should work.
perhaps `nointr' should be the default mount option.
btw the NFS HOWTO recommends hard,nointr
-------------------------------------------------------
This SF.NET email is sponsored by: A Thawte Code Signing Certificate
is essential in establishing user confidence by providing assurance of
authenticity and code integrity. Download our Free Code Signing guide:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0028en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
> -----Original Message-----
> From: Scott Mcdermott [mailto:[email protected]]
> Sent: Wednesday, January 15, 2003 22:38
> To: [email protected]
> Subject: Re: [NFS] Re: Broken umount -f
> But, I still think that with `intr', umount -f should work.
Agreed on that count -- I didn't really mean to suggest otherwise.
Unmounting is orthagonal to signal delivery, so really intr/nointr shouldn't
influence umount -f's behavior.
> btw the NFS HOWTO recommends hard,nointr
I think there was a typo in an some earlier versions -- the current version
of the NFS HOWTO (http://nfs.sourceforge.net/nfs-howto/client.html)
recommends hard,intr.
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Cole, Timothy D. on Thu 16/01 11:45 -0800:
> > But, I still think that with `intr', umount -f should work.
>
> Agreed on that count -- I didn't really mean to suggest otherwise.
I meant, that with `nointr' it should work. I made a couple of typos in
that email :)
> Unmounting is orthagonal to signal delivery, so really intr/nointr
> shouldn't influence umount -f's behavior.
as it is now, with `nointr' the signals aren't delivered when there is
pending IO, apparently (don't know if that's what really happens in the
kernel)
> > btw the NFS HOWTO recommends hard,nointr
>
> I think there was a typo in an some earlier versions -- the current
> version of the NFS HOWTO
> (http://nfs.sourceforge.net/nfs-howto/client.html) recommends
> hard,intr.
I think I read it wrong. I seem to have dyslexia or something...
anyways thanks to all for this useful discussion, I have remounted my
systems with intr and that solution is good enough for now.
-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs