[Drbd-dev] Running Protocol C with disk cache enabled

[Graham, Simon]

> > > acknowledged prior to the failure. Now, I think that the activity
> log
> > > maintained by the Primary actually includes the necessary
> information
> > > about blocks which should be resynchronized _but_ I don't see any
> code
> > > that would actually add these blocks to the bitmap when such a
> failure
> > > occurs.
> > >
> >
> > Right we do not do this. The current opinion on this is: If the
> > disk reported IO completion it has to be on disk. (actually a point
> > of view of the Linux-2.2 and Linux-2.4 time).
> 
> Me and Phil had a few words about this.
> 
> Now, lying hardware is sooo broken :(
> but, anyways.
> 

Well, I look at this slightly differently; use of the on-disk cache is
really the only way to get decent (i.e. competitive) performance out of
rotating rust, so what we have to do is find ways to allow this and
still be correct.

BTW: another case that is of interest to me is when you have a caching
controller -- even though these have battery backup, there is still the
case to worry about when the controller itself fails (something we have
to worry about when building fault tolerant servers) -- in this case, it
should be possible to repair/replace the failed controller and then
reboot and have DRBD resync correctly...

> 
> we would basically maintain the activity log on the secondary
> as well, and introduce an additional "cleanly detached" flag.
> 
> whenever you attach it again, the extents covered would need to be
> resynced.  obviously this behaviour should be configurable, you want
to
> disable it for good hardware and large activity log.
> 
> I can think of few possible optimizations, even...
> but we should not over-engineer what is "just" a workaround.
> 

I thought about this too -- however, I managed to convince myself that
it isn't necessary to store the AL on both disks since we can use the AL
from the disk that was primary (wouldn't they be identical?) -- maybe
there's a case I'm not considering though.

Would it be enough to modify the code to add the current AL to the
in-memory and on-disk bitmaps on the primary whenever you lose contact
with the peer??? I realize this is different from how it is handled for
the loss-of-primary case...

Simon