Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi all We're trying to upgrade our 0.7 DRBD disks to 0.8. We're running 2 machines, ares and athena, in a heartbeat-failover cluster. We've been following this guide: http://fghaas.wordpress.com/2007/10/03/step-by-step-upgrade-from-drbd-07-to-drbd-8/ step-by-step. However, we get this rather ominous warning when doing the "drbdadm create-md" step: > md_offset 310068375552 > al_offset 310068342784 > bm_offset 310058876928 > > Found ext3 filesystem which uses 302670080 kB > current configuration leaves usable 302791872 kB > > ==> This might destroy existing data! <== > > Do you want to proceed? > [need to type 'yes' to confirm] After looking at the kB sizes, it seems there are 118.9375 MB space left for meta-data. Maybe this is not sufficient? This is tried on athena, which was upgraded to lenny and drbd0.8. On our other machine, ares, we still run etch and 0.7. We tried to go ahead despite the warning, as a test. We figured we'd be able to replicate the data from ares if everything fails. This had the following result: > You want me to create a v08 style flexible-size internal meta data > block. > There apears to be a v07 fixed-size internal meta data block > already in place on > /dev/disk/by-id/scsi-SATA_ST3320620NS_5QF5M1E8-part3 > at byte offset 309934161920 > > Convert the existing v07 meta-data to v08? > [need to type 'yes' to confirm] yes > > Converting meta data... > Writing meta data... > New drbd meta data block sucessfully created. > > --== Creating metadata ==-- > [..survey..] > > success Now, if you notice the byte offset, it is _exactly_ equiv. to the size mentioned in the "ext3 filesystem which uses"-line, that is, 302670080kB. The disk on athena worked fine after the upgrade, it seems. But we really have no way to be sure it doesn't contain hidden corruptions. What should we do? We really don't want to take chances with our data, but we also need to upgrade to lenny/0.8, or at least resynchronize the servers very soon, to avoid running on a single server. We're looking for any kind of hints or ideas you might have. Please, if you can, respond quickly. We need to get our storage setup back online. -- Med venlig hilsen / Best regards Christian Iversen Sikkerhed.org ApS Fuglebakkevej 88 E-mail: support at sikkerhed.org 1. sal Web: www.sikkerhed.org DK-2000 Frederiksberg Direkte: ci at sikkerhed.org