[Drbd-dev] Why does resync-cache uses LRU, rather than a queue, as its mechanism.

[Lars Ellenberg]

On Thu, Feb 02, 2012 at 11:12:36PM +0800, carlos_wang wrote:
> 2012/1/29 carlos_wang <1988wzc at gmail.com>
> 
> > Hi all:
> >         I got a problem in understanding why resync-cache uses LRU as its
> > mechanism. I think that a queue is enough to realize the LRU functions. Why
> > does it use LRU anyway?
> >
> >         Thanks in advance.
> >
> >         Carlos.
> >
> Blocks may be "resynced" by new application writes as well.
> 
> Thanks, but according to the code,

I wrote it. Usually I know what it does.
Sometimes I even remember why it does things the way it does ;-)
Though I'm not saying that was the only way to do things.
MD raid solves its own very similar problem differently.

> Once application writes on a DRBD
> device, act_log will cache the active sector in al_extent, writes the last
> extent in lru list on the disk, And never known by resync extent, of course
> in right connection. How blocks know "resynced" by new application
> writes? When drbd begin resyncing, the sector will start from the first
> sector to last sector, so I think it's no need to use LRU as its resync
> mechanism.

Even *during* resync, there are application writes.

Besides, just curious here, why do you even care?

What are you trying to do, prove, disprove, improve?
What is you interest in DRBD in particular?
Anything we can help you with?

Cheers,

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com