Linux NFS development
 help / color / mirror / Atom feed
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

           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