Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Wednesday 22 October 2008 10:13:19 Lars Ellenberg wrote:
> On Wed, Oct 22, 2008 at 09:39:43AM +0200, Andrew McGill wrote:
> > 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.
>
> why would we want to do that.
Because md recovery is painful under load ...
# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[0] sda1[1]
152512 blocks [2/2] [UU]
md1 : active raid1 sdb3[0] sda3[1]
1959808 blocks [2/2] [UU]
resync=DELAYED
md2 : active raid1 sdb5[0] sda5[1]
306544192 blocks [2/2] [UU]
[=>...................] resync = 9.4% (28959168/306544192)
finish=11301.1min speed=408K/sec
> you can use md for that.
If our customers didn't sleep and give the server a break at night we wouldn't
try to use md at all.
> > 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....)
>
> we replicate _below_ the file system for a reason:
> to be file system/application agnostic.
If filesystems agnostically conspired to reserve blocks on request, you could
replicate above and below.
> we do not have a journal (yet),
> at least nothing of the kind you seem to think of.
Yep.
&:-)