At 12:00 AM -0500 12/2/05, Jeffrey Altman wrote:
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? [...]
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.
Most of our (RPI) users are editing files which are not being
modified by multiple users. They can get to their files right
now, and get their work done. While there is a problem right
now, it's a problem that "enough" people are aware about, and
which in practice has not caused much grief.
Admittedly it does occasionally cause SOME grief, so I certainly
do want to see this fixed. I am really happy that progress is
being made on this issue. But this fix is going to disrupt the
presently-working situation for some of our users, and it would
be better if it initially shows up as an option.
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.
We (RPI) already have thousands of laptop users who use the
OpenAFS client. I think that is at least 1/3 of all the machines
on campus which would possibly install it. We are already past
the point of "widely-used"!
At what point in time will it become easier?
In my case, I would hope that the official 1.4.1 release ships
with this improvement implemented, but turned off by default.
Some later release (in two or three months) could ship with it
available, but turned on by default. And a later release could
ship with the option only there to produce a warning ("This
option no longer supported!"), and everyone gets locking.
As long as we get to the point where the official version has
this support always turned on before the summer starts, I think
that will be fine for RPI purposes.
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.
We will be no better off if everyone avoids this release due to
reports of others having "Nightmare Problems!(tm)" with disruption
due to this release.
Also, might it be possible to have an option such that if any
client *does* successfully lock the file, then other 1.4.1 clients
will honor that lock. But if the lock fails (due to the missing
K access), then things go on as they currently do?
--
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute or [EMAIL PROTECTED]
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
