From: Kern S. <ke...@si...> - 2005-01-29 22:27:15
|
Hello, On Tue, 2005-01-18 at 10:05 +0100, Ludovic Drolez wrote: > David Boyes wrote: > > I think what he's asking is whether the > > write_block_to_dev/read_block_to_dev routines are the only marshalling > > point for actually committing data to tape and reading data from tape. > > If that is the case, then that's where he needs to coordinate the > > multiple tape streams, and the RAIT code could pretty easily be patched > > in at that point. He'll also need to modify the autochanger code to > > recognize a certain volume name pattern that indicates a volume set > > (rather than an individual volume), and expand the pattern to multiple > > mount requests. > > Yes, currently I have two solutions to implement RAIT : > > 1- Modify dev.c and block.c and add RAIT code which is already available on > Amanda. Unfortunately, Amanda code is modular while Bacula isn't. If > write_block_to_dev / read_block_to_dev routines are the only marshalling > point for reading/writing data, then it should be "easy" to add RAIT. > > 2- Write a device driver, with the help of FUSD, so that bacula (or any other > backup program) will see only one virtual tape device. For that, bacula needs to > write data with a fixed block size. > > With both solutions, a new tape changer script is needed. One issue that you will need to deal with is that Bacula, unlike Amanda, is quite "intelligent" when doing restores. It basically will position the tape to the correct file/block and then read. On a restore with RAIT, you will either need to disable the positioning code, which would be a huge time penalty when restoring one or two files from a Job, or you will need to handle the "seeks" that Bacula does. That particular code is "grotesquely" complex because it attempts to handle all the different types of OS/tape drives that exist -- a rather impossible task. > > > Regards, > -- Best regards, Kern |