Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi, another two wishes to make DRBD more network friendly: 1) compress/zip the data sent over the network to the peer. 2) in the initial sync, do not blindly send all the data from primary to secondary. Compute a md5/sha1 on both sides and only send the actual data if they differ on primary and secondary. No 1 reduces data volume to at least 50% for average files. No 2 will dramatically speed up initial sync, if i prepare the lower devices on both sides before setup with dd if=/dev/zero of=/dev/sd... Best Regards Matthias Andrew McGill schrieb: > On Tuesday 21 October 2008 23:35:27 Lars Ellenberg wrote: >> I think in all areas drbd does better than nbd/iscsi + md raid1, >> but I am happy to hear all ideas, and use them as inspiration >> for future linux storage replication solutions. > Inspiration. Happiness. Can try. But no promises. > > drdb cannot be a plug-in replacement for md raid1, as far as I know, since two > drbd peers require two systems (or some very careful configuration on one > system). > > It would be rather useful if one *could* replace MD RAID1 with DRBD. For > example, if you could replicate a disk to a USB device, you could use drbd to > make physical snapshots for off-line backups. You could also do a large sync > over a local bus, rather than the network. > > Apart from getting two DRBD instances on one machine, the biggest ease-of-use > barrier to to settings things seems to be attaching the correct meta-data to > a block device -- the meta data does not seem to just know which device it is > for. > > I think that the things that would make it easier are: > > * The ability to store DRBD meta-information *inside* the filesystem (not > over VFS, but in a similar way to the ext3 /.journal if the filesystem > supports immovable blocks). (It sounds easy, if you don't think about it.) > Hands up everyone who uses ext3 with an external journal ... > > * An implicit way for DRBD to find its meta information - e.g. explicit > config, internal meta-data, then on-filesystem meta-data, then a labelled > device. > > (And if you can do this, the next request will be that DRBD makes use of the > filesystem's journal, rather than using its own....)