linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Mark_H_Johnson.RTS@raytheon.com
To: trond.myklebust@fys.uio.no
Cc: linux-kernel@vger.rutgers.edu, linux-mm@kvack.org,
	linuxguy@directlink.net
Subject: Re: Updates to /bin/bash
Date: Fri, 5 May 2000 08:32:46 -0500	[thread overview]
Message-ID: <852568D6.004A028D.00@raylex-gh01.eo.ray.com> (raw)


Just to recap & make sure I have this straight.

 (1) IF I'm dealing with local files & do NOT have the area NFS mounted, then
the typical methods of updating files is OK.

 (2) IF I'm dealing with NFS mounted files, all bets are off. Please confirm
that I should take some action (e.g., remount the volume) to make sure the state
is purged after the updates are made.

I can see that how the second situation works has an impact on diskless (or
small disk) workstations [seems to cause lots of administrative headaches that I
would like to avoid]. I'm in the middle of planning the deployment of a few
clustered systems (head node w/ up to 40 compute nodes) as well as 100-200
workstations for development. If I understand this right, I should spend a
little more money to put bigger disks on each machine & have most of the OS and
tools hosted on each machine. Then use rdist or similar method to keep the
machines updated. Restrict the use of NFS mounting (with appropriate controls)
for the items I just "have to share". [this may also explain why we've had
problems on our currently deployed systems using NFS... Hmm.]

Thanks for the explanations.
--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>


|--------+---------------------------->
|        |          Trond Myklebust   |
|        |          <trond.myklebust@f|
|        |          ys.uio.no>        |
|        |                            |
|        |          05/05/00 02:14 AM |
|        |          Please respond to |
|        |          trond.myklebust   |
|        |                            |
|--------+---------------------------->
  >----------------------------------------------------------------------------|
  |                                                                            |
  |       To:     Matthew Vanecek <linuxguy@directlink.net>                    |
  |       cc:     linux-kernel@vger.rutgers.edu, linux-mm@kvack.org, (bcc: Mark|
  |       H Johnson/RTS/Raytheon/US)                                           |
  |       Subject:     Re: Updates to /bin/bash                                |
  >----------------------------------------------------------------------------|



>>>>> " " == Matthew Vanecek <linuxguy@directlink.net> writes:

    >> On 4 May 2000, Trond Myklebust wrote:
    >>
    >> >Not good. If I'm running /bin/bash, and somebody on the server
    >> >updates /bin/bash, then I don't want to reboot my
    >> >machine. With the above
    >>

     > You wouldn't have to reboot.  Why would you think you need to
     > reboot?  This isn't Winbloze, for god's sake.  All it means is
     > that new bash processes will use the updated version, while old
     > processes would still be using the old version--it's loaded in

NO. This behaviour is exactly what Andreas patch would break. New
processes would get a mixture of old and new versions because the page
cache itself would be out of sync.

     > memory, remember?  Hell, you can even overwrite the libc on a
     > running system.

That is only true of files on local storage. We are discussing NFS,
which is a stateless file system.

Cheers,
  Trond
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

             reply	other threads:[~2000-05-05 13:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-05-05 13:32 Mark_H_Johnson.RTS [this message]
  -- strict thread matches above, loose matches on Subject: below --
2000-05-04 19:53 Mark_H_Johnson.RTS
2000-05-05  0:14 ` Matthew Vanecek
2000-05-05  7:14   ` Trond Myklebust
2000-05-06 13:15     ` Andrea Arcangeli
2000-05-06 17:02   ` Steve Dodd

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=852568D6.004A028D.00@raylex-gh01.eo.ray.com \
    --to=mark_h_johnson.rts@raytheon.com \
    --cc=linux-kernel@vger.rutgers.edu \
    --cc=linux-mm@kvack.org \
    --cc=linuxguy@directlink.net \
    --cc=trond.myklebust@fys.uio.no \
    /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