[OpenAFS] 1.4.1-rc2 build question

[Neulinger, Nathan]

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?

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.=20

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.

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

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-6679
UMR Information Technology             Fax: (573) 341-4216
=20

> -----Original Message-----
> From: openafs-info-admin@openafs.org=20
> [mailto:openafs-info-admin@openafs.org] On Behalf Of Terry McCoy
> Sent: Thursday, December 01, 2005 4:27 PM
> To: openafs-info@openafs.org
> Subject: [OpenAFS] 1.4.1-rc2 build question
>=20
>=20
> Wondering if it would be possible to build 1.4.1 Release Candidate 2
> without support on the server side for Windows byte range locking?
>=20
> Why would you want to do this?
>=20
> It appears that various non Windows locking related issues are getting
> addressed within 1.4.1 such as:
>=20
>   - A bug in callback handling for readonly volumes in the=20
> Unix clients
>     has been fixed.
>   - MacOS 10.3 support has been updated.
>   - Several MacOS 10.4 issues have been addressed.
>   - A memory leak in Rx has been corrected.
>   - A lock leak in Rx has been corrected.
>=20
>=20
> But it is not clear (at least to me) if they are being=20
> inserted into the
> 1.4.0 tree.  Perhaps they are and I am just not up to speed=20
> on using the
> source repository.
>=20
> Anyway from the looks of it there is no way I would envision=20
> quickly migrating
> my cell to a code based that supports Windows byte range=20
> locking.  Our cell
> is very large with +7,000 users, +25 million files and 6TB of=20
> storage being
> used.  Hence the significant educational effort and possible=20
> changes to the
> Windows users experience with issues of being unable to=20
> access files that
> were previously accessible will be a major obstacle in moving=20
> forward at
> large sites.
>=20
> Please note that, I do support moving forward and adding=20
> features such as
> locking and data encryption into the file system.  But=20
> adoption of these
> features should be blance with how existing site will be able=20
> to migrate
> to use them.
>=20
>=20
> +--    --    --    --    --    --    --    --    --    --   =20
> --    --    --   +
> |                                                            =20
>                 |
> |  Terry McCoy                                  email: =20
> terry@nd.edu          |
> |  Sr Systems Engineer                          phone:  (574)=20
> 631-4274        |
> |                                                            =20
>                 |
> |  Office of Information Technologies                        =20
>                 |
> |  315 Information Technology Center                         =20
>                 |
> |  University of Notre Dame                                  =20
>                 |
> |  Notre Dame, Indiana  46556                                =20
>                 |
> |                                                            =20
>                 |
> |                                                            =20
>                 |
> |  perl -e 'print=20
> $i=3Dpack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' |
> |                                                            =20
>                 |
> +--    --    --    --    --    --    --    --    --    --   =20
> --    --    --   +
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20
>=20