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
prev parent 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).