Allowing only 32 tapedrives is seriously shortsighted. The number of
tapedrives directly limits the amount of data one can put in a cell;
if you can't back it up, you should not put it in the cell.
The ASSUMPTIONS:
Exabyte 8200's. (That's all I have time data for.)
Full backups must be done within a 24 hour period.
Full backups are done one day per week.
There are no network problems durring backups. (very optimistic)
There are no AFS problems durring backups. (very optimistic)
One tape takes 3 hours to write. (very optimistic)
All tapes have no errors and are the correct length. (ify)
backup has zero overhead per volume set. (30mins/set actually)
use just one cell.
The NUMBERS:
1 tape drive can write (24hrs/day / 3hrs/tape ) 8 tapes/day.
in 1 day you can write (8 * 32) 256 tapes
in 1 day you can backup 512G of data.
The ANALYSIS:
512G per cell is the upper bound on data a site can store in AFS given
the above assumptions. That's not reasonable for an upper limit. It
may be ok for small sites, but not for large sites.
If "4 gazillion" tape drives is not reasonable then you need to
determine an upper bound of data that you will allow a user to backup
in one day and then state the AFS backup capacity as: "you can backup
up to N Gigabytes/day using AFS."
The above assupmtions are very very generous, and I doubt one could
actually backup 256G of data/day/cell in the current state of affairs.
// sm
// Stergios Marinopoulos Tue Dec 8 15:37:28 1992
// [EMAIL PROTECTED]
I guess you could always run multiple cells, but that seems like
extreme overhead just to get more tapedrives.
On December 7 (Mon) [EMAIL PROTECTED] wrote:
++
++ >Why 32? Why not 4 gazillion...
++
++ We thought that increasing the number of port offsets to 32 was
++ reasonable.
++
++ >Seriously, why not make it something so large, yet reasonable, such that
++ >we won't have to bother you guys in the next 5 to 10 years. How about 256?
++
++ We'll take your suggestion into consideration. However, we're unable to make
++ any promises at this time. We'll be better able to determine any restrictions
++ when we start work on this feature.
++
++ Thanks for your input!
++
++ Kathy
++
++
