[OpenAFS] File locking
Daniel Wood
danw@compbook.co.uk
Fri, 15 Jul 2005 15:08:57 +0100
This is a multi-part message in MIME format.
--==_14081064912523==_
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C5894F.1F671C40"
------=_NextPart_000_0032_01C5894F.1F671C40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi all,
I am looking into implementing OpenAFS over a network comprised mainly =
of Windows clients. Having installed v1.3.84 on a Linux server, the =
system is working fine so far. The ability to manipulate volumes (such =
as moving between servers) to such an extent is particularly useful!
I was wondering what the progress was as regards byte-range locking. =
Having searched a lot on the subject of file locking (and having had to =
learn a few things!), I have determined that OpenAFS utilises advisory =
whole-file locking but not byte-range locking. Thus Windows =
applications such as Microsoft Office which utilise byte-range locking =
are very dangerous on an AFS network due to the fact that two =
applications can read/write to a file. As an aside, why do Office apps =
use byte-range locking when they effectively lock the whole file?
Having looked at archived mailing list messages referring to Stage 1/2 =
locking in AFS, I was curious as to the status of any work so far? =
Ideally (and assuming I'm vaguely right!) a mechanism whereby a file is =
locked on the server to prevent writes (and either reads as well or =
notifying the user the file is read-only as per Office) whilst enabling =
byte-range locks in the cache would suit our purposes, since we use =
shared drives where multiple users will access documents but must not be =
allowed to change them at the same time. This I believe is referred to =
as Stage 1?
I get the impression that work on this would be at a tangent to the way =
AFS works, however that Stage 1 is feasible?
Any corrections to my technical knowledge are most welcome, and any =
thoughts on a timescale in which this might be done if it can be done =
would be nice (though I do realise that's a hard thing to answer!).
Without implementation of this feature I don't think we will be able to =
use OpenAFS which is a shame because it does it's job well! I don't =
think we can risk the possible loss of information it could cause, even =
if it is a somewhat unlikely prospect.
Thanks for your time,
Dan
------=_NextPart_000_0032_01C5894F.1F671C40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1498" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi all,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I am looking into implementing OpenAFS =
over a=20
network comprised mainly of Windows clients. Having installed =
v1.3.84 on a=20
Linux server, the system is working fine so far. The ability to =
manipulate=20
volumes (such as moving between servers) to such an extent is =
particularly=20
useful!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I was wondering what the progress was =
as regards=20
byte-range locking. Having searched a lot on the subject of file =
locking=20
(and having had to learn a few things!), I have determined that OpenAFS =
utilises=20
advisory whole-file locking but not byte-range locking. Thus =
Windows=20
applications such as Microsoft Office which utilise byte-range locking =
are very=20
dangerous on an AFS network due to the fact that two applications can=20
read/write to a file. As an aside, why do Office apps use =
byte-range=20
locking when they effectively lock the whole file?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Having looked at archived mailing list =
messages=20
referring to Stage 1/2 locking in AFS, I was curious as to the status of =
any=20
work so far? Ideally (and assuming I'm vaguely right!) a mechanism =
whereby=20
a file is locked on the server to prevent writes (and either reads as =
well or=20
notifying the user the file is read-only as per Office) whilst enabling=20
byte-range locks in the cache would suit our purposes, since we use =
shared=20
drives where multiple users will access documents but must not be =
allowed to=20
change them at the same time. This I believe is referred to as =
Stage=20
1?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I get the impression that work on this =
would be at=20
a tangent to the way AFS works, however that Stage 1 is =
feasible?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Any corrections to my technical =
knowledge are=20
most welcome, and any thoughts on a timescale in which this might be =
done if it=20
can be done would be nice (though I do realise that's a hard thing to=20
answer!).</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Without implementation of this feature =
I don't=20
think we will be able to use OpenAFS which is a shame because it =
does it's=20
job well! I don't think we can risk the possible loss of =
information it=20
could cause, even if it is a somewhat unlikely =
prospect.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for your time,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Dan</FONT></DIV></BODY></HTML>
------=_NextPart_000_0032_01C5894F.1F671C40--
--==_14081064912523==_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
This e-mail and the information contained is confidential and is intended solely for the person to whom it is addressed.
If you are not the intended recipient or have received it in error we would appreciate a prompt notice that it has been wrongly despatched and will reimburse any reasonable cost involved in notifying us. We thank you for your help in this regard.
We would also advise that you should not use, disclose or copy this information in any medium, as if you do, you may be breaking the law and thereby incurring liability.
We do not accept any liability to any third party acting or failing to act on, or on any information contained in this e-mail
--==_14081064912523==_--