Bacula-users

Re: [Bacula-users] rescan after corrupted catalog - another question?

2013-02-20 09:35:42
Subject: Re: [Bacula-users] rescan after corrupted catalog - another question?
From: Konstantin Khomoutov <flatworm AT users.sourceforge DOT net>
To: "Michael Stauffer _g" <mgstauff AT gmail DOT com>
Date: Wed, 20 Feb 2013 18:33:02 +0400
On Wed, 20 Feb 2013 08:01:48 -0500
"Michael Stauffer _g" <mgstauff AT gmail DOT com> wrote:

> Regarding my situation of a corrupted catalog that I'm trying to
> recover from.
>  
> The only table that was reported problematic was Files, with the
> Files.MYD unreadable.
>  
> Can I do a bscan with all the other tables and files in place to make
> it go faster? How would I do that? Would I leave Files.MYI also in
> place? 

Foo.MYD and Foo.MYI are files representing the on-disk storage of a
MySQL table named "Foo" maintained by the MyISAM storage engine -- the
table data (hence "D") and table indexes (hence "I"), correspondingly.

Now let's look at how bscan works: it sequentially reads the supplied
volumes, extracts the information of jobs written onto them and meta
infomation on files written within those jobs (file size, UID, GID,
permission bits, ctime and mtime; may be something else as well).
This information is inserted into the catalog.

Now it should be apparent that basically what you're really asking is
"whould bscan be able to go faster if I would have in place all the
tables required by the database schema used by Bacula except for the
table `Files'?".  I don't know for sure but I'm pretty much confident
the answer is "of course, no".  That's purely from the implementation
standpoint: try to imagine yourself in the boots of someone
implementing bscan -- would you envision a situation where the user
might have all the required data in the catalog *except* information on
files?  Highly unlikely -- simply because supporting this would mean the
need to implement reconciling the data already in the catalog with the
data scanned from the volumes.

Also, since the volume data is read sequentially anyway, and amount of
information pertaining to jobs is diminishingly small compared to the
amount of information pertaining to files, the prospective speedup from
not inserting information on jobs into the catalog would be negligible.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users