From: Jeff Layton <jeffrey.b.layton@lmco.com>
To: beowulf@beowulf.org
Cc: Alvin Oga <alvin@Maggie.Linux-Consulting.com>, nfs@lists.sourceforge.net
Subject: Re: network storage solutions - mounts
Date: Thu, 15 May 2003 13:37:00 -0400 [thread overview]
Message-ID: <3EC3D03C.7050907@lmco.com> (raw)
In-Reply-To: <Pine.LNX.3.96.1030514202659.14731A-100000@Maggie.Linux-Consulting.com>
Alvin Oga wrote:
> On Wed, 14 May 2003, Glen Kaukola wrote:
>
> > Alvin Oga wrote:
>
> some kernel folks will tell you that using soft mount WILL cause
> corrupt data ... and that hard mount is better...
>
This is correct. The NFS homepage will explain this pretty
clearly and there's a link to a paper by Chuck Lever at
Netapps that explains it as well:
http://www.netapp.com/tech_library/3183.html
I'm cc-ing the NFS mailing list perhaps they can comment
on this.
> i prefer soft mount ... as i want the other machines to keep going,
> even if one of the other boxes died for some reason
>
> if using hardmounts, everybody sits and wait for the other server
> to come back online... if and when it does, and if it comes up
> at some other ip# or some other nfs ports, other pcs need to be
> rebooted too
> - i dont like waiting around or rebooting
>
> hard mount vs soft mount is another vi vs emacs warz
> but at least there's more technical justifications for the reasons
> ( i've not seen any corrupt data due to soft mounts
> -
> - have seens lots of people that cannot work due to hard mounts
> - onto servers that died
> -
>
I would hazard to say that you've been luckly. However,
the potential is there for corrupt data. I would rather wait
on the server to come back than take a chance on corrupting
data.
> trick is NO rebooting allowed, under any condition ... NOT allowed
> - find another way to fix the problem
> ( well, only the last person in the list/responsibility hits
> ( the button
>
> > On the odd chance my boss does buy some duplicate
> > storage, what would you recommend I use to manage it?
>
> software raid ... on 4 IDE ports ... one drive per cable
>
> for NFS .... i'd use soft mounts
>
I'll let other people from the NFS list comment here. However,
I'd say this is risky and something I would do - especially if
you value your data.
Jeff
>
> and NOBODY gets to reboot/touch any server ...
>
--
Jeff Layton
Senior Engineer - Aerodynamics and CFD
Lockheed-Martin Aeronautical Company - Marietta
"Is it possible to overclock a cattle prod?" - Irv Mullins
-------------------------------------------------------
Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
The only event dedicated to issues related to Linux enterprise solutions
www.enterpriselinuxforum.com
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
parent reply other threads:[~2003-05-15 17:45 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <Pine.LNX.3.96.1030514202659.14731A-100000@Maggie.Linux-Consulting.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3EC3D03C.7050907@lmco.com \
--to=jeffrey.b.layton@lmco.com \
--cc=alvin@Maggie.Linux-Consulting.com \
--cc=beowulf@beowulf.org \
--cc=nfs@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.