Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, Oct 5, 2012 at 7:59 PM, Dan Barker <dbarker at visioncomm.net> wrote:
> I just lost a disk on my secondary node. I looked EVERYWHERE and can't find
> the spare disks I bought for such an occurrence. So, I put in a handy disk,
> twice the size.
>
> drbdadm create-md r1
> drbdadm attach r1
>
> and off we go.
>
> If memory serves, create-md will build a meta-data at the END of the disk.
> Won't that cause a lot of seek to the hub when seeking to about the middle
> of the platters would have done the trick, had the metadata been at the same
> offset as the primary?
Well if you had created a partition (/dev/sdc1) rather than use the
full disk (/dev/sdc), then you could have set up that partition to
match the size of the disk on your primary.
Besides, if you're using a RAID controller with a
battery/flashed-backed write cache then it won't matter much. I wrote
about this years ago on my blog:
http://fghaas.wordpress.com/2009/08/20/internal-metadata-and-why-we-recommend-it/
> version: 8.4.0 (api:1/proto:86-100)
> GIT-hash: 28753f559ab51b549d16bcf487fe625d5919c49c build by root at DrbdR0,
> 2012-05-28 12:09:30 (Yes, I know. I need to upgrade).
True. Rather urgently if you're on 8.4.0.
> Failed disk: WD 500G
> Replaced by: WD 1T
> On server: DrbdR0
>
> cat /etc/drbd.d/r1.res
> resource r1 {
> on DrbdR0 {
> volume 0 {
> device /dev/drbd1 minor 1;
> disk /dev/sdc;
> meta-disk internal;
> }
> address ipv4 10.20.30.46:7790;
> }
> on DrbdR1 {
> volume 0 {
> device /dev/drbd1 minor 1;
> disk /dev/sdc;
> meta-disk internal;
> }
> address ipv4 10.20.30.47:7790;
> }
> startup {
> become-primary-on DrbdR1;
Why? Your cluster manager (typically Pacemaker) should take care of
that for you.
Cheers,
Florian
--
Need help with High Availability?
http://www.hastexo.com/now