On 5/21/2011 8:57 AM, Pawel Jakub Dawidek wrote:
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.
Possibly, but this policy is not very
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 f
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
ca
On 5/17/2011 1:28 PM, Maxim Sobolev wrote:
The next thing to make it usable is to make "async" mode working. I
think simple support for that mode can be easily implemented by not
sending write request to the remote note at all, but instead just doing
it locally and kicking the synchronization thr
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
ca
