Large volumes

[David J. M. Karlsen]

Craig_Everhart at transarc.com wrote:

>It may not be faster, but if an operation fails and has to restart, it
>will lose only the update attempt for one volume, or up to 10GB to
>retransmit, not 30GB.  And it will take a while to transmit 10GB, so a
>
>failure is likely.  I don't know what today's transfer rates are, but
>it's likely in the few-MB per second.  Even saying 10MB/second (perfect
>utilization of a 100Mbps link), that's a thousand seconds to transmit
>10GB, or around 20 minutes. 
>
Hm, am I missing someting here.

Scenario I: To volumes of 10 GB each. 1 GB changes on both volumes. The 
outage occurs. Server is back. Replication starts on vol1 and vol2.

Scenario II: One volume of 20GB, 2 GB changes. Outage occurs. Server 
back. Replication of 2 GB of vol1 starts.

Same time - same files - same problems? The thing is: I may want 
directories bigger than 8GB (all the 8GB in one dir - no subdirs) - so 
making multiple volumes is not an option.

>By the way, you might want to reconsider the second level of your tree
>under /afs; it's conventional to put a cell name there so that you might
>someday be able to deal with multiple cells.
>
ah -yes - the domainname by convention. Is OpenAFS in the same state as 
CODA - allowing a client to belong to one, and only one, cell at a time?

/afs/mydomain.com/data1
/afs/mydomain.com/data2

where data1 needs to hold over 10Gb. (More like 60GB)

>>that's why I want to go for one big volume: /afs/data
>>
>
>It's far less failure-prone to have many smaller volumes.  Remember that
>you'll replicate the mount points as you replicate the parent volumes,
>so that you *will* have multiple copies of the same stuff.
>
Yeah - that's my goal for the cluster  - so if one server fails - my 
services (and their data) will continue to serve.

Why I want large vols:
-less administration
-need for many large files within the same directory