[OpenAFS] 1.4.1-rc2 build question
Terry McCoy
terry@nd.edu
Thu, 1 Dec 2005 21:17:54 -0500 (EST)
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.
> 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
> 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).
+-- -- -- -- -- -- -- -- -- -- -- -- -- +
| |
| Terry McCoy email: terry@nd.edu |
| Sr Systems Engineer phone: (574) 631-4274 |
| |
| Office of Information Technologies |
| 315 Information Technology Center |
| University of Notre Dame |
| Notre Dame, Indiana 46556 |
| |
| |
| perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' |
| |
+-- -- -- -- -- -- -- -- -- -- -- -- -- +