Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: DRBD: Users

Re: drbd-user Digest, Vol 11, Issue 23

 

 

DRBD users RSS feed   Index | Next | Previous | View Threaded


mvolaski at aecom

Jun 25, 2005, 9:46 AM

Post #1 of 2 (993 views)
Permalink
Re: drbd-user Digest, Vol 11, Issue 23

>/ 2005-06-25 03:44:03 -0400
>\ Maurice Volaski:
>> >But now I have to shrink one. That's more complicated. The question
>> >is whether drbd resize will know to use the filesystem's size, which
>> >is correct, or the lvm size, which, since it hasn't been reduced yet,
>> >is wrong? If it picks the wrong one, should I give it the
>> >filesystem's exact size (fdisk -s device)?
>>
>> The way I did it was to create the logical volume, drbd device and
>> filesystem in the correct size on the second system with it being
>> unconnected. I used fdisk -s to find out filesystem's corrected
>> (shrunken) size (in K). That means that the size parameter to pass to
>> drbdsetup's resize is that size + exactly 128 MB (in K).
>
>fdisk -s gives you the size of the partition,
>not the "filesystems's exact size",
>so it will give you the size of drbd,
>no hint of where to shrink to.
>but you typically tell the "resize filesystem" operation,
>to which size you want to resize to. then, that should be the size.

The wrong logical volume was 375 GB. My goal was to make it 370 GB,
to shrink it by 5 GB.
fdisk -s on this one was 393084928K. That's 374.875 GB, which is
exactly 128 MB smaller than the logical volume. I'm assuming drbd
metadata sits in that space.

On the right one, logical volume is 370 GB and fdisk -s reported
387842048K, which is 369.875 GB, which is also exactly 128 MB smaller
than the logical volume.

So for the wrong one above, I passed 387842048K to resize2fs and the
value 387973120K, which is really the size of the logical volume, 370
GB, to drbdsetup resize. And finally passed 370G to lvreduce.

Are you saying my math doesn't add up?


>btw, you do NOT want to resize a drbd with internal meta data.
>really.
>use external meta data (that is easy on lvm).
>
This is scary. Why? Is this in the docs anywhere or even on the
mailing list? What bad will come of it? (So far, it is syncing like
the others, no errors...yet).

Anyway, it seems I should be creating a separate logical volume just
to store all the metadata? If I do that now, will drbd know to
relocate the existing meta-data or will I have to start fresh and
sync everything from scratch?
--

Maurice Volaski, mvolaski [at] aecom
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user


Lars.Ellenberg at linbit

Jun 26, 2005, 10:59 AM

Post #2 of 2 (937 views)
Permalink
Re: Re: drbd-user Digest, Vol 11, Issue 23 [In reply to]

you should use a threading aware mailer.
would make your threads more readable.

/ 2005-06-25 12:46:25 -0400
\ Maurice Volaski:

> Are you saying my math doesn't add up?

I just suggest that you have to be careful.

> >btw, you do NOT want to resize a drbd with internal meta data.
> >really.
> >use external meta data (that is easy on lvm).
> This is scary. Why?

because I say so *gee*
no:
because internal meta data is located in the last part of the device.
if the device changes size, the meta data changes position.
so it has to be moved.
_during_ the move, if something bad happens,
you might end up in a situation where drbd has to recreate it.
still, if you know what you are doing, no damage done,
but I'd rather avoid that...

--
: Lars Ellenberg Tel +43-1-8178292-0 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com :
__
please use the "List-Reply" function of your email client.
_______________________________________________
drbd-user mailing list
drbd-user [at] lists
http://lists.linbit.com/mailman/listinfo/drbd-user

DRBD users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.