Bacula-users

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

2013-02-20 11:17:44
Subject: Re: [Bacula-users] rescan after corrupted catalog - another question?
From: "Michael Stauffer _g" <mgstauff AT gmail DOT com>
To: "'Konstantin Khomoutov'" <flatworm AT users.sourceforge DOT net>
Date: Wed, 20 Feb 2013 11:14:28 -0500
> 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.

OK thanks very much. That makes sense. I'll build from scratch.

-M


------------------------------------------------------------------------------
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