Hello Lars,<br><br>Here's mine <span style="line-height:19.7999992370605px">sectors data:</span><div><span style="line-height:19.7999992370605px"><br></span></div>$ sfdisk -d<br><br>Warning: extended partition does not start at a cylinder boundary.<br>DOS and Linux will interpret the contents differently.<br># partition table of /dev/sda<br>unit: sectors<br><br><br>/dev/sda1 : start= 2048, size= 25165825, Id=83<br>/dev/sda2 : start= 25169920, size= 1048577, Id=83<br>/dev/sda3 : start= 26220544, size=2147483649, Id=83<br>/dev/sda4 : start=2173706240, size=3685736448, Id= f<br>/dev/sda5 : start=2173708288, size=1860173825, Id=83<br>/dev/sda6 : start=4033884160, size=1825558528, Id=83<div><br></div><div>So looks like you're right. Just 1 sector above your number. </div><div>Will try to compile HEAD drbd. Is it stable enough to be used on production servers?</div><div><br></div><div>Regards,</div><div>Alex</div><div><br><div class="gmail_quote">On Mon Jan 26 2015 at 11:27:18 Lars Ellenberg <<a href="mailto:lars.ellenberg@linbit.com">lars.ellenberg@linbit.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sat, Jan 24, 2015 at 04:01:11PM +0200, Alex Vasilenko wrote:<br>
> Hello,<br>
><br>
> Having a strange behavior using drbd 8.4.5. After restart one partition of<br>
<br>
TL;DR: for the fix scroll ahead.<br>
<br>
You should always tell both kernel *and* userland versions.<br>
<br>
<br>
> Jan 24 14:42:39 de kernel: block drbd0: disk( UpToDate -> Failed )<br>
<br>
That may look scary, but is normal: during detach (down),<br>
we move via "Failed" to "Diskless" to avoid various potential races.<br>
<br>
> Now trying to restart backup partition:<br>
><br>
> > $ sudo drbdadm down backup<br>
> > $ sudo drbdadm up backup<br>
> > strange bm_offset -65608 (expected: -65600)<br>
> > No valid meta data found<br>
> > Command 'drbdmeta 1 v08 /dev/sda3 internal apply-al' terminated with exit<br>
> > code 255<br>
<br>
<br>
> Somehow metadata is not there anymore (?!). Note warning saying "strange<br>
> bm_offset -65608 (expected: -65600)".<br>
> Ok, how about recreate metadata and resync full partition? Trying to wipe<br>
> old metadata shows that metadata is not present. Ok, let's pretend it's not<br>
> there:<br>
><br>
> > $ sudo drbdadm create-md backup<br>
> > strange bm_offset -65608 (expected: -65600)<br>
> > strange bm_offset -65608 (expected: -65600)<br>
> > md_offset 1099511623680<br>
> > al_offset 1099511590912<br>
> > bm_offset 1099478036480<br>
> > Found ext3 filesystem<br>
> > 1073709016 kB data area apparently used<br>
> > 1073709020 kB left usable by current configuration<br>
> > Even though it looks like this would place the new meta data into<br>
> > unused space, you still need to confirm, as this is only a guess.<br>
> > Do you want to proceed?<br>
> > [need to type 'yes' to confirm] yes<br>
><br>
> initializing activity log<br>
> > NOT initializing bitmap<br>
> > Writing meta data...<br>
> > New drbd meta data block successfully created.<br>
> > success<br>
><br>
><br>
> Same warning twice<br>
<br>
So what. During "probing", some validation is done with various<br>
potential contexts. But it keeps being "strange", which is reported.<br>
<br>
> possible wrong fs detection (in fact it's ext4) and<br>
<br>
ext2, 3, 4, who cares. for this purpose, keeping you from shooting<br>
yourself by truncating an existing file system, they are the same.<br>
They don't differ in their "master magic",<br>
but only in by feature flags, which are irrelevant for us.<br>
<br>
> incorrect data usage detection (in fact takes 533GB of 1Tb partition)<br>
<br>
How much "payload" you stored in the file system is irrelevant,<br>
we care about the size of the file system itself,<br>
and that you won't truncate it.<br>
<br>
It may well still be completely "empty", it still would be very unhappy<br>
if you truncated the data area it thinks it owns exclusively.<br>
<br>
> Wiping and creating metadata again fixes bm_offset warning until next drbd<br>
> service restart.<br>
<br>
Yup. The kernel sanity checks are less picky when attaching the first<br>
time, and just fixes the broken offsets drbdmeta put there.<br>
<br>
> Having latest Centos 6.5. Kernel 2.6.32-504.1.3.el6.x86_64<br>
> Disks are based on hardware RAID 1.<br>
><br>
> $ sudo fdisk -l<br>
<br>
Next time use "sfdisk -d" (to get the exact sectors,<br>
not some rounded last-millenium cylinder numbers),<br>
or better yet, show "blockdev --getsize64 /dev/X"<br>
<br>
> backup uses /dev/sda3 and main uses /dev/sda6<br>
<br>
> Can someone hint me what's wrong am I doing? Will provide any additional<br>
> info on request.<br>
<br>
The fix:<br>
<a href="http://git.linbit.com/gitweb.cgi?p=drbd-utils.git;a=commit;h=7969b9dc6636b5543d16b7b09ae267abc64ca111" target="_blank">http://git.linbit.com/gitweb.<u></u>cgi?p=drbd-utils.git;a=commit;<u></u>h=<u></u>7969b9dc6636b5543d16b7b09ae267<u></u>abc64ca111</a><br>
| drbdmeta: fix regression corner cases in bitmap size calculation<br>
|<br>
| Regression was introduced with the kernel/userland split.<br>
| Regression was caused underestimating the number of bytes by<br>
| not aligning the number of bits to 64 before converting to bytes<br>
| (dividing by 8).<br>
<br>
Apparently, your sda3 just happens to be of some "odd" size,<br>
just above 2147483648 sectors, (hex: 0x80000000).<br>
(if it was exactly that, you would not have triggered the bug).<br>
<br>
<br>
--<br>
: Lars Ellenberg<br>
: <a href="http://www.LINBIT.com" target="_blank">http://www.LINBIT.com</a> | Your Way to High Availability<br>
: DRBD, Linux-HA and Pacemaker support and consulting<br>
<br>
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.<br>
__<br>
please don't Cc me, but send to list -- I'm subscribed<br>
______________________________<u></u>_________________<br>
drbd-user mailing list<br>
<a href="mailto:drbd-user@lists.linbit.com" target="_blank">drbd-user@lists.linbit.com</a><br>
<a href="http://lists.linbit.com/mailman/listinfo/drbd-user" target="_blank">http://lists.linbit.com/<u></u>mailman/listinfo/drbd-user</a><br>
</blockquote></div></div>