Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wed, Sep 26, 2007 at 05:56:42PM +0800, Petr Cervenka wrote: > Lars Ellenberg wrote: > > > > well. > > I guess you used internal meta data. > > if the RAID got it right, then all the old data is still there, > > lying at "the end" of the previous device, so somewhere at 220G. > > drbd only looks for its meta data at the end of the device, > > so at offset ~400G currently. > > there is nothing but nonsense there. > > > > you have to create new drbd meta-data then, > > as if you'd set it up for the first time. > > > Aha, well this is just test before we go live, so no damage there, so is > it better to store metadata in another disk , can this be just file? How > big does it have to be? As we expect to expend the disk more often. How > come with LVM this works? Does LVM extend differently ? resizing with internal meta data is fragile, and works only when you can do the resize while drbd stays online. while it is running, it sort of "knows" where its meta data lies, and can the relocate it when told so. if it crashes/is unconfigured/unloaded when the device is already resized, but before the meta data got relocated, sorry, out of luck. resizing works much better with external meta disk, since the data there does not have to be relocated. it cannot be a file. you could fake a file to be a disk with losetup, but don't do that. it introduces a potential for deadlock, because block io re-entering file-io path. it has to be a "partition", "logical volume" or something like that. man drbd.conf should tell you the rest. -- : Lars Ellenberg http://www.linbit.com : : DRBD/HA support and consulting sales at linbit.com : : LINBIT Information Technologies GmbH Tel +43-1-8178292-0 : : Vivenotgasse 48, A-1120 Vienna/Europe Fax +43-1-8178292-82 : __ please use the "List-Reply" function of your email client.