On Wed, Feb 24, 2010 at 6:40 PM, Christopher <[email protected]> wrote: > Was it always that way? I haven't used amrestore since amfetchdump came > out.
Yes. Or, if not, it was a bug :) > I'll spend some time tracking down exactly what is not being stripped > out. Maybe stderr is being included? My C programing skills are weak, > so I might not be able to provide a patch, but I can do the legwork to > find out exactly where the problem data is. Currently my amdump runs > last 19 to 23 hours. I got a third tape drive for the jukebox > specifically to be able to do restores without killing the running > amdump. So being able to run amrestore without a workaround would be > good (amfetchdump --yes-I-know-what-I-am-doing --ignore-running-amdump > --use-drive /dev/nst2 would be better :). In the example I gave the > data was only 25G, but the same workaround would be "interesting" with a > -gt 1Tb restore. Stderr would not be included in the shell pipeline you pasted. If you can figure out what message is being included, you can probably comment it out. amrestore has been completely rewritten in 3.1, so there's no sense producing a patch. amidxtaped is careful to only try to lock the config if the tape drive it's using is the same as the default for the config. I thought amfetchdump did the same thing, but perhaps not. Anyway, amfetchdump has also been rewritten (all of the recovery tools have been rewritte - amidxtaped should be committed in a day or two once I sort out some Amanda-2.4.5-compatibility issues), and now does not try to lock the config at all. By the way, the new code manages to not stomp on its own feet by reserving particular volumes and/or drives in the changer, rather than locking the entire config. Dustin P.S. You give yourself away as a shell programmer when you write "-gt 1Tb" ;) -- Open Source Storage Engineer http://www.zmanda.com
