linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Brian Candler <B.Candler@pobox.com>
Cc: Linux RAID <linux-raid@vger.kernel.org>
Subject: Re: Removing a failing drive from multiple arrays
Date: Thu, 26 Apr 2012 17:17:58 -0400	[thread overview]
Message-ID: <4F99BB86.6000104@tmr.com> (raw)
In-Reply-To: <20120426132336.GA12692@nsrc.org>

Brian Candler wrote:
> On Thu, Apr 26, 2012 at 08:59:01AM -0400, Bill Davidsen wrote:
>>> Another option, although I've not done this for a long time, is PXE boot.
>>> You need a DHCP server giving out the correct parameters and a TFTP server
>>> for the kernel (and ramdisk?)
>>>
>> I think that's addressing one point of failure while adding more.
> Alternate point of view: you need reliable DNS anyway, and it's no harder to
> make reliable DHCP than reliable DNS (you just have two of them).
> Furthermore, this only needs to be available at the time a server boots up.
>
> I worked in one place where they made all the servers (which were VMs) pick
> up their IPs via DHCP.  This allowed them to dump the images across to the
> disaster recovery site, boot them up there, and bring them all up on new IPs
> without touching any configs.  It worked well.  They ran DHCP service on the
> Cisco L3 switches that the VM hosts were plugged into, on the basis that
> this was the most reliable kit that they had.
That is why my DNS/DHCP server is so vital :-(
I have been doing my IP assign that way for some years, and using the ability of 
KVM to set the MAC of the VM so I can take a fairly standard image and change 
the name of the machine and IP at boot time. I have had less luck getting IPv6 
working "right" and at the moment the IPv6 enabled servers get their IP from DNS 
look-up on their name, and their name from DHCP in IPv4. It's ugly but solid, 
I'm in not rush to find out why my IPv6 DHCP is unreliably.
> Like you say, it's a balancing act of cost, complexity, and reliability, and
> is also coloured by experience.  I've had not-so-good experiences with USB
> thumb drives.
>
I've had failures on the old ones due to write cycle fatigue. Once written it 
should be stable as a read-only device. That's my thinking, if SSD is reliable, 
then thumb drives should be slow but reliable, too. I'm saying that, feel free 
to provide your opinion or contradictory facts. I take little on faith myself.

-- 
Bill Davidsen<davidsen@tmr.com>
   We are not out of the woods yet, but we know the direction and have
taken the first step. The steps are many, but finite in number, and if
we persevere we will reach our destination.  -me, 2010




      reply	other threads:[~2012-04-26 21:17 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19 18:54 Removing a failing drive from multiple arrays Bill Davidsen
2012-04-19 21:52 ` NeilBrown
2012-04-20 14:30   ` Bill Davidsen
2012-04-22 22:33   ` Bill Davidsen
2012-04-22 22:55     ` NeilBrown
2012-04-25  0:07   ` Bill Davidsen
2012-04-20 14:35 ` John Stoffel
2012-04-20 16:31   ` John Robinson
     [not found]     ` <CAK2H+efwgznsS4==Rrtm6UE=uOb25-Q0Qm84i8yAJEJJ2JLdgg@mail.gmail.com>
2012-04-22 18:41       ` John Robinson
2012-04-26  2:37         ` Bill Davidsen
2012-04-26  6:19           ` John Robinson
2012-04-26  7:36           ` Brian Candler
2012-04-26 12:59             ` Bill Davidsen
2012-04-26 13:23               ` Brian Candler
2012-04-26 21:17                 ` Bill Davidsen [this message]

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=4F99BB86.6000104@tmr.com \
    --to=davidsen@tmr.com \
    --cc=B.Candler@pobox.com \
    --cc=linux-raid@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).