[ENBD] raid1 mirroring inside enbd

[chacron1]

"A long time ago Peter T. Breuer" wrote:

>
>
> > What block size do you use ?
>
> On resync, the blocksize of the device, which is normally 4KB. When in
> normal operation, the size of the request, which can be anything up to
> the limits currently in force (I use 128KB normally, i.e. 32 blocks ).

OK, it makes sense for me.

>
> > Does the enbd driver update the bitmap on disk on every write
>
> There is no bitmap on disk at the moment. A "notuptodate blocks" bitmap
> is kept in memory, and a resync thread will only update the blocks that
> are marked in it. They're marked when a write to that component of
> the device cannot be completed.
>

Are there two memory bitmaps on both sides or only one on the side where the write()
requests are locally write on disk and also sent through the network to the other side ?
In the later case what is the behavior whenever the primary side failes ?


>
> If you replace the whole (remote) resource, you will have to force
> the whole bitmap to be dirtied - perhaps with a "setbroken" command
> instead of a setfaulty.

OK.

>
> > ( performance will be downgraded compared to a hardwrae RAID1 if it is the case ) .
>
> Performance is currently quite degraded anyway, as I am trying to get
> it right before I get it fast! Each write request from the kernel has to
> be treated twice, once for each destination, which means two copies to
> use space, and two network transfers.
>

It seems you don't use BH to avoid data copy ?
Do you mean one data send and one acknowledgement message ?




>
> OTOH reads are handled by the first currently availble component.
>
> It is becoming more usable, because I am using it myself in some test
> setups. I have only just got it to set itself up to more than just
> localhost, and now I will have to make the bitmap more sparing of
> kernel memory by using a two or three level map. Otherwise terabyte
> sized devices would use up something 30MB of kernel memory as bitmaps!
> Well, twice that, one for each component. Only a page at a time needs
> allocating, really.

If 3 level bitmaps then you will maybe need a lock to protect access on it
or not depending how many threads may have concurrent on it ?

Eric