On Tue, May 17, 2011 at 12:39:19PM -0700, Maxim Sobolev wrote: > Hi Pawel, > > I am trying to use hastd(8) over slow links and one problem is > apparent right now - current approach with synchronizing content > sequentially is not working in this case. What happens is that hastd > hits the first frequently updated block and cannot make any progress > anymore. In my case I have 30GB of dirty space to be synchronized > over just 1mbps uplink. > > The quick fix that I've applied is randomization in the block > selection code. This way eventually all least used blocks will be > synchronized, leaving only hot ones dirty. More effective approach > would be to use some kind of LRU selection algorithm, but > statistical approach would work just as good in this case. > > Please review the patch below: > > http://sobomax.sippysoft.com/activemap.c.diff Hmm, hastd keeps separate bitmap for synchronization. It is stored in am_syncmap field. Blocks that are dirtied during regular writes should not effect on synchronization bitmap and synchronization progress. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:14 UTC