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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox