Ok thanks a ton for explaining, the only point left is read-write and read-only and how to separate those. So far it sounds like I will need to have a setup like /afs/public/data1 /afs/public/data2 /afs/public/data3 /afs/user1/data1 /afs/user2/data2 etc
Where /afs/public is a read-only replicated 'master' copy and /afs/userx is users individual read-write folders, and /public needs to be synced "manually". Is this right - i.e. is this the kind of semantics that OpenAFS implies? Mike -----Original Message----- From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.org] On Behalf Of Lars Schimmer Sent: Friday, April 30, 2010 4:43 PM Cc: openafs-info@openafs.org Subject: Re: [OpenAFS] Getting started with OpenAFS -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mike Pliskin wrote: > Dear Lars, (please, TOFU) > Thanks a lot for the detailed response, let me see what I can do in terms of > partitions. Generally the task I am trying to solve is the following: > - there is a 100-gigabyte collection of large files (10 mb to 1 gb) No problem, we have >5 TB of data in OpenAFS which includes files of 20GB so far. But for files >4GB you need at least a client version >1.4.0. > - there are several geographically distributed sites with people that > need access Readonly access or read/write access the same data or different directories? Thats a important point as only one read/write copy of a volume/directory can exist in one OpenAFS cell. > - files are organized in folders, and there is a fairly good > administrative separation on who needs which files - i.e. chances of > people writing the same file at once are pretty low You can set ACLs on directories in OpenAFS - fairly simple and works. > - speed is important as well as a way to access any file from > anywhere (but ok to degrade speed if replicas aren't synced yet) Readonly replica could be done via night and clients can access a local readonly replica for faster access (if a local fileserver exists). The client cache could do a difference, to. Needs to be big enough (for bigger files) and persistant over reboots. If a file could be served out of client local cache and not from (slow) server overseas fine. > So the question is - do you think OpenAFS is a right tool for this problem? So far yes. BUT the read/write and readonly point is still open. You could setup one volume per directory and mount that directories after the rules of rw access into the filetree. But if you have e.g. a /afs/test/useraa/files/ firectory for user aa on a fileserver in dk and a user bb in the US needs to write to that directory, it needs to access that fileserver the rw volume is on. If user bb in the us need only to access a readonly copy of that directory, copy that volume/directory to the us fileserver (over night) and the user bb could access it readonly from the us local fileserver. Hope it is made clear now why it needs some think-over with a multi-homing site. But it is absolute possible and could work great. > Thanks, > Mike > MfG, Lars Schimmer - -- - ------------------------------------------------------------- TU Graz, Institut für ComputerGraphik & WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkva0DYACgkQmWhuE0qbFyMBEACggL2GZC31kpZ5u8BIoNFUep+n iB0Anixf9lxO3b/R+QktJUUH61GW01Kn =6Yr5 -----END PGP SIGNATURE----- _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
