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: [EMAIL PROTECTED] | | 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);' | | | +-- -- -- -- -- -- -- -- -- -- -- -- -- + _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
