[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Alternative DB structures-Porposal

> > Reading a 20 TB file twice is nontrivial. I have LOTS of files that
> > large, and a few that will grow into exabyte-scale in the not too
> > distant future.
> I think we should just exclude those from consideration. What exactly,
> can we back up a exabyte file to? A billion CD's!

On the other hand, these are EXACTLY the files that need the database
support most. Why would you want to exclude a real case that supports
your argument? 

(BTW, today, you store petabyte and exabyte-class datasets on 1 inch
optical tape. About 350 TB/volume for the current generation, due to go
up to about 600 TB in the next year or two with more efficient lasers
and some of the material science research going on at 3M in the US, Univ
Monash in Australia, and Siemens in Germany.)
> If you must use bacula, for your (very much smaller 20Tb files) then
> nothing
> On those systems, you don't have a filesize for the reasons given. But
> you  already don't a have a filesize,
> so adding a size field to the catalogue changes nothing. Set it to
> or the number of blocks or something.

Which is exactly what I suggested. In the general case, a file size is: 

Number of units * unit size. 

If unit size = 1, you trivially get the current semantics, and you lose
a few bytes in the database storing the extra binary 1 for the unit size
repeatedly. If unit size > 1, you lose a few bytes in the database and
save boatloads of client backup time waiting for the FD system to get
the info for the attribute packet. 

Everybody wins. 

-- db

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.