[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?
Thanks,
Thomas
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