[OpenAFS] Is locking (flock) on OpenAFS reliable?

Jeffrey Altman jaltman@your-file-system.com
Mon, 04 Jul 2011 08:52:55 -0400


This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFF9632E90EF1C777BD19EE63
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Matthias:

As far as I am aware, the 1.4.x exclusive lock processing on UNIX is
broken in that it does not properly ensure that file data modified under
the lock is stored to the file server prior to the lock being dropped.
There are a number of other lock related issues that were corrected on
the master branch as well.

The 1.6pre* releases on UNIX should to the best of my knowledge do the
right thing with regards to lock acquisition and data synchronization.

On Windows, all versions from 1.4.1 have implemented byte range locks
enforced with full file locks from the file server.  Two applications
running on the same machine can synchronize their operations using byte
range locks.  Two applications on separate machines will see all byte
range lock requests behave as full file locks.  Prior to 1.5.75, the
Windows clients failed to ensure that file length changes and data
modifications performed under the full file lock were written back to
the file server when the last byte range lock was dropped.

In both UNIX and Windows, file server locks are obtained with a five
minute lease which must be renewed.  If the client is unable to renew
the lease, the file server will release the lock.  If a file server lock
is lost and the client cannot re-obtain it under the same data version,
the client must invalidate the file descriptor to prevent potential data
corruption from occurring.

Jeffrey Altman


On 7/4/2011 7:06 AM, Matthias Gerstner wrote:
> Hello,
>=20
> I wonder what the status of using flock calls (or the flock utility)
> with OpenAFS is. Generally it seems to work to synchronize different
> machines with each other using flock on OpenAFS. But in practice I
> encountered inconsistencies.
>=20
> When doing research about this topic I found no real reliable
> information what OpenAFS does intend to provide in this area. I know
> that byte-range locking is not supported between multiple machines. But=

> that doesn't matter for me.
>=20
> So what I encounter particularly is the following:
>=20
> I'm using flock to safely get a copy of a small directory tree on AFS. =
A
> central machine in the network updates that data regularly so I want to=

> be able to get a consistent copy from other machines. This works well
> for most of the time but every now and then I get the following error:
>=20
> /usr/bin/flock: 3: Input/output error
>=20
> Also when testing flock interactively between different machines it
> seems that sometimes it works as expected and then at other times more
> than one machine obtains the lock at the same time.
>=20
> No obvious errors can be found in client kernel logs or server logs. I
> primarily use OpenAFS on Gentoo Linux currently at version 1.4.14. But =
I
> experienced the problems for a long time already not only with this
> specific version.
>=20
> Another question I have is whether locking should also work from Window=
s
> OpenAFS clients. I'm using cygwin on Windows7 and try using flock there=

> on OpenAFS files and it seems to do something but I'm not sure if it's
> doing the right thing.
>=20
> I'd be happy to hear any advice on this.
>=20
> Best regards,
>=20
> Matthias
>=20


--------------enigFF9632E90EF1C777BD19EE63
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJOEbetAAoJENxm1CNJffh426AH/3Zy3rZXpX7McB8GDhlVm/fv
2rmmjeTnaP4R5k7W7Gt7RShhCtFeniXY2AQ60ZugPPbqwqf4v/jwsV9vZ59AqtTN
rIZaYPQlJvF6ysCqSMDF6lhLnP4hoeqqD/Rp84p5Ij+uVtUWLy/ta/1xo7al+Zu0
ig/afIHGcPsiozQooSWNbAxp+v76dHSVThrj/+9igbczQirBpn3L8sXhQ+wkoRKN
9G53OgurxhMuzGzbtWIeLZ3oKeEcO8OBQLKwptW5Zc22CXxJB2sgPE9fj0z+zcie
VYs2zvuI4QHAHA2YD10Q9NBvr5zdEYYRnc1JR21KODigTzAf7T54/OWZr2M+8ME=
=m1uA
-----END PGP SIGNATURE-----

--------------enigFF9632E90EF1C777BD19EE63--