Hello Craig,
Thanks for the very kind email, and the well balanced presentation of some of
Bacula's features that can be improved :-)
Concerning automatic handling of LVMs: I think it would be a nice feature,
where I hesitate is that it is OS dependent, and 99% of the directives we
have (not all) are OS independent. That means that before implementing
something like that, we need to give it very careful consideration.
On the question of lstat in the database: yes, a number of people have
requested what you are suggesting. The problem of just putting the lstat
packet in the database is two fold:
1. Without careful though, it would very significantly increase the size of
the database and possibly slow down record insertion. The size issue is
really quite worrisome. Your statement that PostgreSQL would be as efficient
as the current base64 encoding is interesting and worth understanding ...
2. The current lstat is not really system independent (I forgot that the silly
mode bits can differ from Unix to Unix).
Item 2 is just something to consider when we re-work the lstat packet -- it
probably needs to be a part of the project.
Item 1 is much more problematic. Eric and I have been working on a design for
making selected parts of the lstat more accessible (i.e. have them as
separate table columns -- perhaps Eric could dig out our notes on this
subject). There are fields that we can totally eliminate, and that would
largely compensate for the extra space taken by adding new separate columns,
but for 3.0, we decided not to make any changes since all the design issues
were not totally clear. One important aspect is the requirement to convert
existing databases.
You certainly have the right attitude by mentioning MySQL and SQLite. One
important point is that we need to be as SQL engine neutral as possible (not
always so easy).
If you would like to work on either or both of these projects, we would be
very happy, but as you can see, I feel we need to carefully design what will
be done before coding. However, as long as we discuss these points and
resolve as much as possible beforehand, and as you say "assuming perf testing
worked out and it worked OK for MySQL and SQLite as well", I don't see any
problem, and the simple answer is yes, it is OK ...
What do you think?
Best regards,
Kern
On Wednesday 08 April 2009 03:35:50 Craig Ringer wrote:
> Kern Sibbald wrote:
> > On Tuesday 07 April 2009 17:32:27 Reynier Perez Mira wrote:
> >>> 1.Bacula Release 3.0
> >>
> >> When will be Bacula 3.0 released during this week?
> >
> > Since I am working 12-16 hours a day, and I as well as the other
> > developers are doing it all for free: It will be ready when it is ready
> > (during this week).
>
> For what it's worth, as someone who's done my own fair share of OSS dev
> work (on Scribus, PoDoFo, lprof, and misc other things):
>
> *THANKS*
>
> Bacula makes part of my job dramatically simpler, easier, and safer. It
> takes some learning and can take some coaxing to get it to do what you
> want, but once it's set up it *just* *goes*, and it informs you if/when
> something DOES go wrong. I cannot overstate the value of this.
>
> It's also nice to see a project where I start using it and don't
> immediately feel the gotta-fix-that-unfeature/bug/whatever itch. Because
> Bacula already does what I need it to. Ther are things where it could be
> simpler/cleaner/nicer, mostly in configuration, but they're all pretty
> minor.
>
> Other backup systems I've investigated (including several commercial
> ones) have had weird limitations, horrifying UIs (yes, compared to
> Bacula!), and/or scary packaging and setup that makes me reluctant to
> let them anywhere near my servers.
>
> Bacula is already integrated into most of the OSes I use, and trivial to
> install on the others.
>
> Now that it handles deleted files correctly, it's pretty much perfect.
>
> BTW, if I was to find the time to implement native fd support for LVM
> snapshots, so that rather than using pre- and post- scripts for
> snapshots and using path stripping, the user could just specify (eg)
> "lvm_snapshot=/var/spool/cyrus/mail;2GB" in the FileSet options and have
> Bacula take care of managing the snapshot, would that be something you'd
> potentially want to see included?
>
> Also, if I was to submit a patch that changed the database format for
> post-3.0 to store lstat attributes as individual fields in the DB,
> rather than using the almost-base64 encoded strings Bacula currently
> uses, would that be considered? I'd *REALLY* like the ability to query
> those values directly and to create indexes on them, something I can
> currently do only by adding a C helper function to PostgreSQL and using
> functional indexes. Kinda clunky. Since (at least in Pg) storage as
> native values is at least as storage-efficient as the base64 form, would
> this be considered assuming perf testing worked out and it worked OK for
> MySQL and SQLite as well?
>
> >> Is the SVN release ready for production?
> >
> > Yes. This was answered in the first paragraph of the email you are
> > citing ... :-)
>
> I've been using 2.5.42b2 for weeks now, by the way, and the only issues
> I've encountered have since been fixed in svn.
>
> --
> Craig Ringer
------------------------------------------------------------------------------
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
