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

Re: [Bacula-devel] space saving in the database

> Just my opinion, of course.  I'd be interested to hear how much effect
> this would have on others and whether they think it's worthwhile to
> investigate.

Moved and seconded. I don't think the world needs to reinvent
packed-decimal yet again and all the grief that fancy encoding schemes
cause, especially since they tend to fail miserably on different-endian
machines (see ext4 problems on non-Intel architectures -- you were
planning on testing this stuff on PPC and zSeries, right?). This is a
database tuning issue, really -- if your database isn't set up to handle
the volume Bacula generates, then it's time. 

IMHO, you'd get more bang for the work by abstracting the file
parameters into a list of attributes and pointing to those via a table.
That would also give you a lot of the infrastructure necessary to handle
the arbitrary attribute support you need for SELinux, etc, and give you
a good start on being able to deduplicate file data (no point in storing
the same file multiple times). 

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list

This mailing list archive is a service of Copilot Consulting.