Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Tue, Dec 02, 2008 at 08:49:55AM +0100, Peter Funk wrote:
> Hello,
>
> excuse me. I'm new here. I hope I don't violate any policiy
> by jumping in here and stealing this thread.
>
> But Florian Haas wrote 02.12.2008 08:07:
> > ..., and unless you're on an
> > age-old I/O subsystem that doesn't have a RAID controller with
> > battery-backed write cache, just use internal metadata.
>
> What if DRBD is used on top of Linux software RAID?
>
> So imagine off-the-shelf hardware: two boxes with two SATA drives
> each connected to two standard PC motherboards with no
> hardware RAID and no batteries at all involved.
>
> Although this is new hardware I suspect that this situation
> might be somewhat comparable with what you describe as
> "age-old I/O subsystem".
>
> Are there any reasons to not use internal metadata in this situation?
> Does it make any sense to buy for example a CF-Card adapter or a solid
> state disk to store the DRBD metadata on another may be safer device?
see the DRBD external vs internal metadata advantages and disadvantages
in the drbd users guide.
http://www.drbd.org/users-guide/ch-internals.html
the main point is:
if you put your meta data on the same "spindle" (whether using
"internal" or an "external" partition on the same physical device), you
have to pay the seek penalty for every meta data update.
a decent raid controller (with write cache enabled yaddayadda) hides
this penalty from you.
with external meta data, you could put it on a different physical device
("spindle") to avoid the seek penalty.
--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list -- I'm subscribed