Re: [OpenAFS] 1.4.1-rc2 build question

[Jeffrey Altman]

Terry McCoy wrote:

On Thu, 1 Dec 2005, Neulinger, Nathan wrote:

Would it be worth considering having byte range lock support in the
code, but enabled with a flag or option of some sort so that code could
be staged in without fully implementing it?

i.e. similar to fs setcrypt?

That would be a suitable.

But to what extent is it beneficial?   Here is the current situation.
The 1.4.0 and previous clients attempt to obtain a full file lock and
fail and then ignore the error.  Or they obtain the lock but do not
attempt to ensure that it continues to be held and if it is lost, they
make no attempt to prevent further file access.

The end result is that user's of applications such as Microsoft Office
which make extensive use of byte range locks as a form of signaling
not to mention to ensure data integrity lose.   Users don't realize
there is a problem until they close the data file and attempt to re-open
it again.  By that point in time it is too late.

Therefore, your users are already in a situation in which they cannot
safely use AFS as a place for active editing of documents in public
shared spaces.   By implementing Byte Range Locking and you failing
to add 'k' to the ACLs for the shared spaces, the users are not losing
functionality but are being prevented from doing something dangerous.


AFS client was not stable enough to do long term work.  Now it is and
it needs to be safe enough to use as well.   It must provide the same
level of functionality that a user would get from a Windows File Share.

Now is the time to make the transition before there is wide spread
deployment of 1.4.0.  Once there is a widely used stable OpenAFS client
on Windows it is going to be much harder to get your organization to
upgrade let alone any others.

At what point in time will it become easier?

If I provide a way to turn it off, how will you ensure that it gets
turned back on in the future?

The benefits of locking will only be ensured when all of the users
accessing a file are using clients that enforce the locks.  The longer
we wait, the longer and harder it will be to make the transition.

At some point in time we are going to have to make the difficult transition to the use of byte range locks. In the past, the Windows

I don't know if the impact described below is legitimate or not, but
having it in the code but optional is at least a more gradual step-in to
the support.

Does the new byte range support change it from:

        Ignore request, pretend it was granted, don't do any lock
to
        Grant request based on client side decision, with read or write
lock on server

In that case, a lot more read locks would suddenly be getting obtained
by those clients on the server than were getting obtained previously.
Not that this should be a problem, but it might expose other locking
issues elsewhere that would cause hesitancy in adoption of 1.4.1 as a
whole if the feature were forcibly on.

good point

There is very little overhead on the servers for keeping track of locks.
The servers make no effort at the current time to keep track of who has
locks.   Read locks on a file are simply a counter of granted locks that
have not been returned.  The write lock is maintained as a single value
of -1.  The lock values are maintained as long as one request to renew
the lock is received within five minutes of the last grant or renewal
from any client.  (Including a client that did not ask for a lock in the
first place.)

I'm not referring so much to the locks on the client that wants byte
range locks, but on the person who doesn't care, and suddenly can't get
a lock on the file at all because someone else has a lock on it. (Not
that this is a good thing, but it's a noticable change in behavior.)

-- Nathan

I think you also need to consider the interaction within the file system
between pre 1.4.1 Windows clients (no locking) and 1.4.1 Windows
clients (with locking).

The use of old clients vs new clients will exactly the same as if you

and there are no complaints.  If you open with Word first, Wordpad will
be prevented from opening it.

There is going to be a transition period.   The question is whether it
happens now or at some point in the very near future.

Please keep in mind that read-only volumes do not use locking at all.
Any data you are publishing via read-only volumes such as applications
will be unaffected.  Also, any home directories that you have given to
end users more than likely already have the 'k' privilege and if they
do not, the user's can add it since they most likely have 'a' on their
own volumes.

The place where there will be a transition is simply the set of volumes

a friend's volume for which they have 'rl' can still do so.   They just
won't be able to do so using an application that insists on locking it
unless they first copy it to a local disk or to somewhere that they can
obtain a lock.

I am very well aware that the education process is not going to be
limited to any one organization.   I am going to have to come up with a
method of educating the user when the software is installed.  That will
probably involve the creation of a run-once per user application that
provides the user with a lesson on AFS ACLs.

Jeffrey Altman

were to access a file with two different applications that used different locking semantics. For example, you can edit a Word document file with Word or Wordpad. Wordpad does not use locks whereas Word does. If you open first with Wordpad, Word can open the file afterwards in which there is shared use and where people have already granted partial permissions. A user that wants to access a Word document in

smime.p7s
Description: S/MIME Cryptographic Signature