On Mon, Aug 10, 2009 at 06:14:27AM -0700, beelz wrote: > > > Well, I got my AFS server up and running and have a better understanding of > the hierarchy and mount points so please disregard my previous question. I > still don't have LDAP configured but so far I've been able to connect and > move files with a few different client OSs. Very satisfying after a > considerable amount of time spent on this project. > > I've decided to keep my volumes at approximately 100 GB. I do not have > multiple servers and I would appreciate any suggestions people have as to > sizing volumes, and whether there have been any problems with large (like, > around 100 GB) ones. Also, what is a good way to create a volume that will > be shared by multiple users? There's a lot of information about creating > new home directories, but what about those not associated with specific > users? >
Here at UMich we will give volumes out to 100GB or so. Past that they currently are just to unwieldy to move about and to backup smoothly the way we do things. Test that in your environment, though. We like being able to move volumes around and have them backed up, and the way we do things 100GB is the upper limit (currently) for what we feel confortable with. As for shared volumes, we create things called group volumes. I've also seen places call them project volumes, or something similar. When we create a group volume for a project, let's call it `someproject', we do the following: - Create a volume called g.someproject (g. for `group', this is pure convention). - Mount that volume at /afs/umich.edu/group/s/someproject (again, pure convention). - Create a pts group `someproject' that owns itself. - Create a pts group `someproject:members', owned by someproject. - Give `someproject' admin rights to /afs/umich.edu/group/s/someproject and give `someproject:members' write rights to the same directory. - Add appropriate people to the pts groups. I've also been tempted to create `someproject:guests' and give them read-only access. Again, all of this is pure convention, but it seems to work well. -- Thomas L. Kula | [email protected] | http://kula.tproa.net/ _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
