[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);' |
|                                                                             |
+--    --    --    --    --    --    --    --    --    --    --    --    --   +