[Drbd-dev] Behaviour of verify: false positives -> true positives

Thomas Schoebel-Theuer thomas.schoebel-theuer at 1und1.de
Wed Oct 1 11:16:41 CEST 2008

Hi Lars,

I have two different patches, both based on your git version from 2008-09-11.

The first one implements the checksumming method while the second one 
implements the copy method proposed by you.

I found that your suggestion was much more easier to implement than the 
checksumming method. However, the copy method works completely silently (you 
get no response whether a race on the data is actually taking place or not), 
while the checksumming method writes reports to the kernel log (so you can 
observe the behavior).

I have also run some performance tests with iozone, but could not find any 
significant difference between any of the patched and unpatched versions 
(and, of course, no difference between the two alternatives). iozone's 
measurements seem to produce "noise" in the range of about 5%. Theoretical 
considerations tell me that both patches should slowdown overall system 
performance by about 1% at most, so I could not figure out anything with my 
single tests (I had no time for running them repeatedly 100 or 1000 times).

Enclosed you will find both patches. They are intended only for _testing_ 
(e.g. performance benchmarks), not for production use. I would be glad if 
someone could report any experience with it, e.g. performance tests (probably 
with better testing tools).

Currently both methods are enabled by a preprocessor constant (just for 
testing). For production use, we should do it right. Since both methods are 
in fact some sort of "paranoia options" (similar to the CRCs already 
present), I would ask whether we should enable/disable them by drbdadm via 
the kernel interface, leading to a new interface revision [oh, as a side 
note, I found that git revision 2008-09-11 crashed with userspace tools 8.2.5 
although the interface revision claimed to be compatible, or did I miss 
something there?].

Should I do the work on the interfaces also, or do you want to integrate it 
yourself to your systematics?

Another issue with the checksumming method: I had problems interfacing with 
the crypto api (probably a wrongly braced kmap/kunmap bug), and it seems that 
different kernel versions do it differently, so I wrote my own small XOR 
checksum algorithm (almost trivial). I'm not sure whether this quick hack is 
really good. And there is some dead code about the crypto API, which I should 
either remove or clean it up (e.g. by moving global_tfm to struct drbd_conf). 
Currently this is all a little hackish, not for production use. Do you have 
any suggestions how to cleanup this in order to meet your style?



Am Dienstag, 30. September 2008 22:10:16 schrieb Lars Ellenberg:
> On Thu, Sep 11, 2008 at 11:25:12AM +0200, Lars Ellenberg wrote:
> > On Tue, Sep 09, 2008 at 04:02:30PM +0200, schoebel wrote:
> ...
> > > Now I am reasoning on different solutions. Please comment.
> > >
> > > Here are just some brainstorming ideas, without judging on their
> > > quality (this will come later):
> ...
> > how about holding a ring buffer of pinned pages,
> > say "drbd max-buffer" pages plus some,
> > and in drbd_make_request,
> > memcpy(ring buffer, submitted data)
> > then checksum that,
> > and submit it to localdisk as well as to tcp stack.
> > as these are now "private" data buffers,
> > the "application" cannot possibly modify them in-flight.
> have you made any progress on that matter?
> shall we further discuss whether or not it should be "fixed" (in drbd),
> and if so, how?
> or have you decided to just move a long?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: drbd-8.2-checksum.patch
Type: text/x-diff
Size: 7944 bytes
Desc: not available
Url : http://lists.linbit.com/pipermail/drbd-dev/attachments/20081001/0bfe507c/drbd-8.2-checksum.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: drbd-8.2-copy.patch
Type: text/x-diff
Size: 4635 bytes
Desc: not available
Url : http://lists.linbit.com/pipermail/drbd-dev/attachments/20081001/0bfe507c/drbd-8.2-copy.bin

More information about the drbd-dev mailing list