Hang at commit time when using sftp or bzr+ssh

John Yates john.yates at us.ibm.com
Fri Dec 9 16:29:39 UTC 2011


There is a technique I have used and also seen in other caching network 
file systems (e.g. NFS v4).  The states of the system are identified by a 
monotonic counter.  Obtaining a lock returns the current value of that 
counter.  If the counter has not changed since data was last cached 
locally then that data can be reused, otherwise a refresh is necessary.

/john




From:   Aaron Bentley <aaron at aaronbentley.com>
To:     stephen at ck12.org
Cc:     bazaar at lists.canonical.com
Date:   12/09/2011 10:28 AM
Subject:        Re: Hang at commit time when using sftp or bzr+ssh
Sent by:        bazaar-bounces at lists.canonical.com



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-12-08 07:23 PM, Stephen Auyeung wrote:
> Another possibility is caching at the higher level. For example,
> caching the master_branch at Branch. I see the code there, but the
> cache is being cleared when unlock is called and that makes the
> cache not very useful. Could it be that only some of the cache need
> to be clear but not all?

Generally the solution is to hold the lock for longer.  Is there a
reason that wouldn't work here?

I think we want to avoid the possibility of inconsistency clearing
only part of the cache would introduce.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7iKOkACgkQ0F+nu1YWqI14JACeIAAlH8GwPyNgwKBLnOoeMopD
QwsAn1n2dGabEEXeM2CyyYRFsHqdNP9z
=yRsf
-----END PGP SIGNATURE-----






More information about the bazaar mailing list