Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Lars Ellenberg wrote: > / 2006-05-10 09:39:12 -0700 > \ Carson Gaspar: > >>--On Wednesday, May 10, 2006 6:32 PM +0200 Lars Ellenberg <Lars.Ellenberg at linbit.com> wrote: >> >> >>>but then again, once we implement the online >>>verification, we would _need_ to have this initial >>>sync, because the drives _have_ to be bitwise identical >>>(that's one of our "guarantees", after all). >> >>Actually, no - you don't have to do a network sync. >>You can just write zeros on both sides. > > > Oh? That's news! Tell me more :) > > if someone wants to do that, he can of course do that. thats maybe > usefull if you have smallish, fast storage but slowish network. > > I think typically you rather have largish raid5 backend, > and a dedicated GigE link. > Bottleneck is the storage box. so what. > > So, you have to pay for that traffic by MB? > Oops. My bad. > Ok, one more annoying question in drbd8 at meta-data creation time... > > Nothing of this is likely to appear in drbd 0.7, though. > But as already mentioned, you can easily script this. > > Cheers, > Lars, Would it make sense, in 0.8.x or 0.9.x, that when doing a full sync, drbd do a minimal look at the data it is sending and handle "sparse" (large sequences of 0's) data 'efficiently' like tar and cp do, i.e., when drbd notices it is sending 100 4k blocks of data, instead of sending 400k of 0, send a "drbd_sparse 100" packet to the peer which then turns that into 0's on the media? If the users have either zeroed the whole hard drive on the primary, or the unused portion of it, prior to telling drbd to do the initial sync, I think we might get close to what these people are asking for. Of course the down sides to this approach are: 1) it is defiantly a protocol change. 2) someone has to implement it. 3) it may be a little confusing to see 0 packets being passed to the peer for a long time while the primary figures out how many sparse blocks in a row there are. (could be mitigated slightly by having a max number of sparse blocks found before a send.) 4) Really throws off the speed of transfer calculations. :) -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter