Re: [Bacula-users] rescan after corrupted catalog - another question?
> On Wed, 20 Feb 2013 08:01:48 -0500 > "Michael Stauffer _g" 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] rescan after corrupted catalog - another question?
On 02/20/13 08:01, Michael Stauffer _g wrote: > 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? The index file is of no use without the data. MySQL will only have to truncate it anyway. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 ala...@caerllewys.net ala...@metrocast.net p...@co.ordinate.org Renaissance Man, Unix ronin, Perl hacker, SQL wrangler, Free Stater It's not the years, it's the mileage. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] rescan after corrupted catalog - another question?
On Wed, 20 Feb 2013 08:01:48 -0500 "Michael Stauffer _g" 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] rescan after corrupted catalog - another question?
On Wed, Feb 20, 2013 at 08:01:48AM -0500, Michael Stauffer _g wrote: > Hi again, > > 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? > > Thanks, > Michael I don't think this will be possible, as the File table is bound to be your largest table in the database (followed by Path and Filename a distant 2nd and third), so I'd rather play it safe and start with an empty database from scratch. Cheers, Uwe -- NIONEX --- Ein Unternehmen der Bertelsmann SE & Co. KGaA -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
