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, Jun 19, 2009 at 01:18:18PM +0200, Laszlo Attila Toth wrote: > Hi, > > we found a strange behaviour a few days ago as in the following letter: > http://lists.linbit.com/pipermail/drbd-user/2009-June/012176.html I think you refer to this post: On Thu, Jun 04, 2009 at 09:10:06PM +0200, ILLES, Marton wrote: >>> Hi, >>> >>> I have a drbd node running 0.7.23 and upgraded it to 8.3.0, but after >>> the disk is configured the state is showed as outdated. (The >>> configuration currently has no slave node attached it is standalone) Of >>> course I can force it to consistent using "drbdsetup /dev/drbd0 primary >>> -o" command, but i do not like this solution. >>> >>> To upgrade drbd I rebooted the box and before starting anything (before >>> even drbd initialized itself) I ran the following commands: >>> >>> drbdmeta --force /dev/drbd0 v08 /dev/hda3 internal create-md >>> drbdsetup /dev/drbd0 disk /dev/hda3 /dev/hda3 internal --create-device >>> >>> In the logs I could see that it states that 0K was marked out-of-sync. >>> So it looks like nothing is really outdated... >>> >>> This setup is a test environment with no production data on it and it is >>> also in a snapshoted virtual machine, so I was able to do different >>> tests but with the same results. >>> >>> Any ideas what could be wrong? > The output of > drbdmeta /dev/drbd0 v07 /dev/hda3 internal dstate > is: > Inconsistent/DUnknown > > however, after upgrading to v08: > drbdmeta /dev/drbd0 v08 /dev/hda3 internal create-md > > the output of > drbdmeta /dev/drbd0 v08 /dev/hda3 internal dstate > is > Outdated/DUnknown > > I've looked into the source code, how it can be, but I have no idea for > this thing. > > It seems that in md_disk_07_to_cpu() the flags are not filled in, but > the dstate command uses it. It is zero in this case, and this is why the > output is 'Inconsistent/DUnknown'. then the "drbdmeta dstate" for v07 meta data always shows Inconsistent/DUnknown. so what. > In md_convert_07_to_08() the upgrade fills this member from the old > value of the flags (contained by cfg->md.gc[Flags]). v07 doesn't know > the MDF_WasUpToDate flag, but it is used by v08 dstate... Yes. > If the device with v07 format is in inconsistent state, how can it be > outdated after the upgrade? The upgrade sets the MDF_Consistent flag, > because without it the 'Outdated/DUnknown' text wouldn't apper. How can > the MDF_WasUpToDate flag missing? As we already established, the drbdmeta dstate for v07 is broken, and always shows Inconsistent/DUnknown. so it probably was NOT Inconsistent before. that it is "Outdated" afterwards is not a problem. it is intended. drbdmeta has no way of knowing whether consistent v7 data is UpToDate or not. so why should it pretend that. You are supposed to know. If you had them Connected Secondary/Secondary before the upgrade, and tell drbd8 after the upgrade to connect, it should establish that both have the very same data, and go UpToDate. Otherwise, _you_ are supposed to know, and to tell drbd 8. > And after a successful reboot of the system how can be the device in > inconsistent state? I didn't found the related code in the kernel module. You are basing this again on the drbdmeta dstate for v07? But you found out already ... I won't repeat that again. -- : 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