Re: Building amanda on Mac OS X
Stefan G. Weichinger wrote: Which gcc-release is this? What make-binary? Maybe you have hit the same bug as we had on Solaris lately, where the problem was that the system used a non-BSD-version of make (and OSX is a kind of BSD ...). The solution there was to use /usr/ccs/bin/make, but I have no idea if this is it for you and which paths are correct for OSX. For the record, it was not the version of make, but the wrong path before running ./condigure, which did not find the ar tool (and to which configure did not complain as it should). The solution was to set the path to include /usr/ccs/bin before running configure. When doing that, /usr/ccs/bin/make was found too as a side effect, but it would have been possible to run with the solaris 10 default make too, by prepending that dir to the path again. In general I would suggest to use the newer release if possible, also on the server, although at first we have to find out why your make fails ... But I've no idea either for your real problem... Stefan notices I also can't quite tell from your posting where the lines end ... Could it be that your Makefile was messed up (tabs got spaces, \r-\n lineend confusion etc) a -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... Are you sure? ... YES ... Phew ... I'm out * ***
Problems with amverifyrun
Hi all, hopefully someone can help me with the following problem I have: - I'm using amanda with a tape library. - I have configured 4 tapes per run - Backup is working normal (tapes are being skiped as needed) - I'm happy so far After backup I run amverifyrun to check the backup. Now I have the following situation and I don't know if this behaviour is intended or I'm doing something wrong. While making the backup, amanda probably hits the end of the tape. That means a tape file header is written, but the tar in that file is not complete. Amanda starts over to backup this tar-file to the next tape which works fine. But amverifyrun reads any file it finds and tries to read the tar file in there. On the very last file (which was not written entirely) amverify gets an error (of course). Now amverify does some tries to recover, gives up and starts over to verify the files on the new tape. Amverify starts there with the file which was written incompletely on the tape before. So: Logically everything is O.K. because all files which were written completely can be read completetly, but technically some errors happen in the amverifyrun. So amverify sends a report stating many many error. My question: Is there a way to check that backup so that I get an error when there is really an error in the backup set? In this context error means to me that I probably can't restore alle tar-files I backed up before. Thank you in advance Andreas
Re: Problems with amverifyrun
On Fri, Jul 08, 2005 at 10:18:53AM +0200, MATILDA MATILDA wrote: Hi all, After backup I run amverifyrun to check the backup. Now I have the following situation and I don't know if this behaviour is intended or I'm doing something wrong. brief synopsis: on a multi-tape run amverify notes an incomplete dump file at the end of a tape marks that as an error finds the complete dump file on the next tape does not remove the earlier error thus generates a report showing errors My question: Is there a way to check that backup so that I get an error when there is really an error in the backup set? In this context error means to me that I probably can't restore alle tar-files I backed up before. Seems to me that your desired behavior would be reasonable. It could be a real bear to test, having to read through entire tapes before getting to the test point. I hope someone with a vtape test setup can duplicate the problem and use that as a testbed instead. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: exclude list optional not working?
Graeme Humphries wrote: On Wed, 2005-07-06 at 18:34 +0200, Stefan G. Weichinger wrote: After reading all that thread I have to ask: Do you all agree with me editing the man-page as Jon suggested? It seems reasonable to me. Edited and committed to the xml-docs-cvs. -- Stefan G. Weichinger AMANDA core team member mailto://[EMAIL PROTECTED] -- oops! linux consulting implementation http://www.oops.co.at --
Re: Problems with amverifyrun
On Friday 08 July 2005 09:44, Jon LaBadie wrote: On Fri, Jul 08, 2005 at 10:18:53AM +0200, MATILDA MATILDA wrote: Hi all, After backup I run amverifyrun to check the backup. Now I have the following situation and I don't know if this behaviour is intended or I'm doing something wrong. brief synopsis: on a multi-tape run amverify notes an incomplete dump file at the end of a tape marks that as an error finds the complete dump file on the next tape does not remove the earlier error thus generates a report showing errors My question: Is there a way to check that backup so that I get an error when there is really an error in the backup set? In this context error means to me that I probably can't restore alle tar-files I backed up before. Seems to me that your desired behavior would be reasonable. It could be a real bear to test, having to read through entire tapes before getting to the test point. I hope someone with a vtape test setup can duplicate the problem and use that as a testbed instead. I'm running vtapes here. This was indeed true the last time I tried runtapes=2, Jon. There were also some other amverifyish housekeeping problems whose details I don't recall now as that was several (6+) months back up the log and none of the examples now exist. To me, the obvious cure would be to remove the partial file, a piece of cake in a vtape setup, but in a tape environment, that would require keeping track of the fm's so that a backspace could be done and the partial files header overwritten with an EOT marker 32k of /dev/zero before going on to the next tape in the magazine restarting the failed file. Thats a lot of wear and tear on both the tape and the drive IMO, so the real cure should be done in amverify itself. The question then is: can amrecover/amrestore cope properly with this scenario? I do not know, having never tested that exact scenario. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
barcode scanners (or, chg-zd-mtx problem)
Hi, My amanda configuration is working nicely, but i have a problem w/ the barcode scanning stuff. MTX reports all the :VolumeTag=blahblah stuff indicating that my barcode scanner should be working. the tape-changer i'm using is chg-zd-mtx. i a line in my /etc/amana/DailySet1/amanda.conf that says changerfile=/etc/amanda/DailySet1/changer. the changer.conf in that directory is like this: havereader 1 firstslot 1 lastslot 17 cleanslot -1 offline_before_unload 0 but when i run the /usr/lib/amanda/chg-zd-mtx -info' it reports 4 30 1 These values are good (the 30 is what i want, but i changed it to 17 for testing purposes), but they are clearly not what is in my changer.conf. I'm not sure if it's guessing the information on it's own or pulling it from some other file... i read through some of the /tmp/amanda/chg-zd-mtx stuff, but unfortunately they do not tell me what config file it's reading from. Any help would be greatly appreciated. Thanks, Cameron Matheson
Re: barcode scanners (or, chg-zd-mtx problem)
On July 8 2005, Cam wrote: havereader 1 firstslot 1 lastslot 17 cleanslot -1 offline_before_unload 0 but when i run the /usr/lib/amanda/chg-zd-mtx -info' it reports 4 30 1 You need equals signs (=) between the keywords and values in the changer.conf file. Like this: havereader=1 firstslot=1 lastslot=17 cleanslot=-1 offline_before_unload=0 If chg-zd-mtx doesn't find good values for those keywords, it uses mtx to figure them out itself. -Ben -- Benjamin Lewis [EMAIL PROTECTED] Security Analyst, Identity and Access Management IT Security and Privacy Purdue University
Re: barcode scanners (or, chg-zd-mtx problem)
On Fri, 2005-07-08 at 10:34 -0600, Cam wrote: havereader 1 firstslot 1 lastslot 17 cleanslot -1 offline_before_unload 0 but when i run the /usr/lib/amanda/chg-zd-mtx -info' it reports 4 30 1 Where are you running it from? It'll read the config in the local directory (IIRC), so you should run it from your config directory. These values are good (the 30 is what i want, but i changed it to 17 for testing purposes), but they are clearly not what is in my changer.conf. I've noticed that on our Exabyte unit, it *always* reports the number of slots that actually have tapes in them, as opposed to the number of slots I've specified to use, or the total number of slots. I'm not sure if it's guessing the information on it's own or pulling it from some other file... i read through some of the /tmp/amanda/chg-zd-mtx stuff, but unfortunately they do not tell me what config file it's reading from. Any help would be greatly appreciated. What do you have in relation to the changer in your amanda.conf? -- Graeme Humphries ([EMAIL PROTECTED]) Linux Administrator VCom Inc. (306) 955-7075 ext 485 My views and comments do not necessarily reflect the views of my employer.
which tape changer for Qualtstar TLS-4210
Hello. I've been trying to get a tape changer TLS-4210 to work for a while for amanda. I'm unable to get the tape changer to work. For now I've been using the mtx command on a linux machine. The problem is that as soon as I mount a drive. The tape gets stuck and will not eject. Am I using the wrong protocol. The jukebox has worked well before. thankyou Rich #mtx -f /dev/sg0 inquiry Product Type: Medium Changer Vendor ID: 'QUALSTAR' Product ID: 'TLS-4210' Revision: '2.12' Attached Changer: No # mtx -f /dev/sg0 status Storage Changer /dev/sg0:2 Drives, 12 Slots ( 0 Import/Export ) Data Transfer Element 0:Full (Storage Element 5 Loaded) Data Transfer Element 1:Full (Storage Element 12 Loaded) Storage Element 1:Full Storage Element 2:Full Storage Element 3:Full Storage Element 4:Full Storage Element 5:Empty Storage Element 6:Full Storage Element 7:Full Storage Element 8:Full Storage Element 9:Full Storage Element 10:Full Storage Element 11:Full Storage Element 12:Empty
Re: which tape changer for Qualtstar TLS-4210
On Fri, 8 Jul 2005 at 12:13pm, [EMAIL PROTECTED] wrote Hello. I've been trying to get a tape changer TLS-4210 to work for a while for amanda. I'm unable to get the tape changer to work. For now I've been using the mtx command on a linux machine. The problem is that as soon as I mount a drive. The tape gets stuck and will not eject. What do you mean mount a drive? You don't mount tape drives. Am I using the wrong protocol. The jukebox has worked well before. In general, remember that you use 'mtx' to drive the robotics and 'mt' to drive the tape drive(s). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: which tape changer for Qualtstar TLS-4210
Please keep responses on the list, so that everyone can chip in. On Fri, 8 Jul 2005 at 12:48pm, [EMAIL PROTECTED] wrote Quoting Joshua Baker-LePain [EMAIL PROTECTED]: What do you mean mount a drive? You don't mount tape drives. by mount I mean load. For example. mtx -f /dev/sg0 load 12 1 # mtx -f /dev/sg0 unload 12 1 Unloading Data Transfer Element into Storage Element 12...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Illegal Request *snip* Am I using the wrong protocol. The jukebox has worked well before. In general, remember that you use 'mtx' to drive the robotics and 'mt' to drive the tape drive(s). Well, for me mt is another problem, I'm trying to find a way around this issue. # mt -f /dev/sg1 status (done as root) /dev/sg1: Operation not permitted mt works on tape devices, not generic SCSI devices. Try 'mt -f /dev/nst0'. I'd thought the command: # mtx -f /dev/sg0 unload 12 1 would not need to function together with mt. It depends on the loader (and, sometimes, the loader's firmware settings). Sometimes you can just send an 'unload' to the robot and it'll tell the tape drive to eject the tape, and sometimes you need to explicitly 'mt -f /dev/nst0 offline' before the 'mtx unload' will work. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: which tape changer for Qualtstar TLS-4210
mt works on tape devices, not generic SCSI devices. Try 'mt -f /dev/nst0'. I'd thought the command: # mtx -f /dev/sg0 unload 12 1 would not need to function together with mt. It depends on the loader (and, sometimes, the loader's firmware settings). Sometimes you can just send an 'unload' to the robot and it'll tell the tape drive to eject the tape, and sometimes you need to explicitly 'mt -f /dev/nst0 offline' before the 'mtx unload' will work. that seems to have been the case here. Thankyou very much. I'm off to the next problem. Rich
Re: which tape changer for Qualtstar TLS-4210
--On Friday, July 08, 2005 15:03:52 -0400 Joshua Baker-LePain [EMAIL PROTECTED] wrote: Please keep responses on the list, so that everyone can chip in. On Fri, 8 Jul 2005 at 12:48pm, [EMAIL PROTECTED] wrote Quoting Joshua Baker-LePain [EMAIL PROTECTED]: What do you mean mount a drive? You don't mount tape drives. by mount I mean load. For example. mtx -f /dev/sg0 load 12 1 # mtx -f /dev/sg0 unload 12 1 Unloading Data Transfer Element into Storage Element 12...mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Illegal Request *snip* Am I using the wrong protocol. The jukebox has worked well before. In general, remember that you use 'mtx' to drive the robotics and 'mt' to drive the tape drive(s). Well, for me mt is another problem, I'm trying to find a way around this issue. # mt -f /dev/sg1 status (done as root) /dev/sg1: Operation not permitted mt works on tape devices, not generic SCSI devices. Try 'mt -f /dev/nst0'. I'd thought the command: # mtx -f /dev/sg0 unload 12 1 would not need to function together with mt. It depends on the loader (and, sometimes, the loader's firmware settings). Sometimes you can just send an 'unload' to the robot and it'll tell the tape drive to eject the tape, and sometimes you need to explicitly 'mt -f /dev/nst0 offline' before the 'mtx unload' will work. My Qualstars (a TLS-4480 and a RLS-4445) need an offline command to the drive before telling the changer to put away the tape. My changer conf handles this by specifying 'needeject 1'. I'm using chg-qs-mtx, which is a modified chg-mtx. You may need to add a 'sleep' in between, since the mt command can return before the tape is really unloaded. Frank -- Joshua Baker-LePain Department of Biomedical Engineering Duke University -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: Problems with amverifyrun
--On Friday, July 08, 2005 10:58:25 -0400 Gene Heskett [EMAIL PROTECTED] wrote: On Friday 08 July 2005 09:44, Jon LaBadie wrote: On Fri, Jul 08, 2005 at 10:18:53AM +0200, MATILDA MATILDA wrote: Hi all, After backup I run amverifyrun to check the backup. Now I have the following situation and I don't know if this behaviour is intended or I'm doing something wrong. brief synopsis: on a multi-tape run amverify notes an incomplete dump file at the end of a tape marks that as an error finds the complete dump file on the next tape does not remove the earlier error thus generates a report showing errors My question: Is there a way to check that backup so that I get an error when there is really an error in the backup set? In this context error means to me that I probably can't restore alle tar-files I backed up before. Seems to me that your desired behavior would be reasonable. It could be a real bear to test, having to read through entire tapes before getting to the test point. I hope someone with a vtape test setup can duplicate the problem and use that as a testbed instead. I'm running vtapes here. This was indeed true the last time I tried runtapes=2, Jon. There were also some other amverifyish housekeeping problems whose details I don't recall now as that was several (6+) months back up the log and none of the examples now exist. To me, the obvious cure would be to remove the partial file, a piece of cake in a vtape setup, but in a tape environment, that would require keeping track of the fm's so that a backspace could be done and the partial files header overwritten with an EOT marker 32k of /dev/zero before going on to the next tape in the magazine restarting the failed file. Thats a lot of wear and tear on both the tape and the drive IMO, so the real cure should be done in amverify itself. This seems dangerous to me. Besides the fact that some drives don't backspace well (speed-wise), even on a vtape an error in your positioning would cause loss of data. It seems easier and safer to to just have amverify buffer the error and if it is successful in reading the DLE from the next tape don't output the error. Frank The question then is: can amrecover/amrestore cope properly with this scenario? I do not know, having never tested that exact scenario. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: Problems with amverifyrun
On Fri, Jul 08, 2005 at 02:37:30PM -0500, Frank Smith wrote: --On Friday, July 08, 2005 10:58:25 -0400 Gene Heskett [EMAIL PROTECTED] wrote: On Friday 08 July 2005 09:44, Jon LaBadie wrote: On Fri, Jul 08, 2005 at 10:18:53AM +0200, MATILDA MATILDA wrote: Hi all, After backup I run amverifyrun to check the backup. Now I have the following situation and I don't know if this behaviour is intended or I'm doing something wrong. brief synopsis: on a multi-tape run amverify notes an incomplete dump file at the end of a tape marks that as an error finds the complete dump file on the next tape does not remove the earlier error thus generates a report showing errors My question: Is there a way to check that backup so that I get an error when there is really an error in the backup set? In this context error means to me that I probably can't restore alle tar-files I backed up before. Seems to me that your desired behavior would be reasonable. It could be a real bear to test, having to read through entire tapes before getting to the test point. I hope someone with a vtape test setup can duplicate the problem and use that as a testbed instead. I'm running vtapes here. This was indeed true the last time I tried runtapes=2, Jon. There were also some other amverifyish housekeeping problems whose details I don't recall now as that was several (6+) months back up the log and none of the examples now exist. To me, the obvious cure would be to remove the partial file, a piece of cake in a vtape setup, but in a tape environment, that would require keeping track of the fm's so that a backspace could be done and the partial files header overwritten with an EOT marker 32k of /dev/zero before going on to the next tape in the magazine restarting the failed file. Thats a lot of wear and tear on both the tape and the drive IMO, so the real cure should be done in amverify itself. This seems dangerous to me. Besides the fact that some drives don't backspace well (speed-wise), even on a vtape an error in your positioning would cause loss of data. It seems easier and safer to to just have amverify buffer the error and if it is successful in reading the DLE from the next tape don't output the error. Agreed, safety and time make it undesireable to my thinking. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Problems with amverifyrun
On Friday 08 July 2005 15:37, Frank Smith wrote: --On Friday, July 08, 2005 10:58:25 -0400 Gene Heskett [EMAIL PROTECTED] wrote: On Friday 08 July 2005 09:44, Jon LaBadie wrote: On Fri, Jul 08, 2005 at 10:18:53AM +0200, MATILDA MATILDA wrote: Hi all, After backup I run amverifyrun to check the backup. Now I have the following situation and I don't know if this behaviour is intended or I'm doing something wrong. brief synopsis: on a multi-tape run amverify notes an incomplete dump file at the end of a tape marks that as an error finds the complete dump file on the next tape does not remove the earlier error thus generates a report showing errors My question: Is there a way to check that backup so that I get an error when there is really an error in the backup set? In this context error means to me that I probably can't restore alle tar-files I backed up before. Seems to me that your desired behavior would be reasonable. It could be a real bear to test, having to read through entire tapes before getting to the test point. I hope someone with a vtape test setup can duplicate the problem and use that as a testbed instead. I'm running vtapes here. This was indeed true the last time I tried runtapes=2, Jon. There were also some other amverifyish housekeeping problems whose details I don't recall now as that was several (6+) months back up the log and none of the examples now exist. To me, the obvious cure would be to remove the partial file, a piece of cake in a vtape setup, but in a tape environment, that would require keeping track of the fm's so that a backspace could be done and the partial files header overwritten with an EOT marker 32k of /dev/zero before going on to the next tape in the magazine restarting the failed file. Thats a lot of wear and tear on both the tape and the drive IMO, so the real cure should be done in amverify itself. This seems dangerous to me. Besides the fact that some drives don't backspace well (speed-wise), even on a vtape an error in your positioning would cause loss of data. Some tape drives may not be able to backspace, but truely those are early dynosaurs. My experience is with DDS2's and QIC's up to 525 meg capacity. Each and every one has been able to bsb one or more files. Worst come to worst, the tape can be rewound, fsf'd to the head of that file and wipe it from there. OTOH, that would be lots of wear on the drive tape if it occured very often, which it will in a runtapes 1 situation. As far as a vtape loss of positioning is concerned, its A: bloody unlikely, and B: insrantly recoverable by hand because here is a common ls -l obtained directory listing of one of my vtapes: -rw--- 1 amanda disk 10 Jul 8 01:42 0-Dailys-2 -rw--- 1 amanda disk 32768 Jul 8 01:42 0.Dailys-2 -rw--- 1 amanda disk 12 Jul 8 01:43 1-gene._usr_src.1 -rw--- 1 amanda disk9469952 Jul 8 01:43 1.gene._usr_src.1 -rw--- 1 amanda disk 11 Jul 8 01:44 2-gene._root.1 -rw--- 1 amanda disk1048576 Jul 8 01:44 2.gene._root.1 -rw--- 1 amanda disk 11 Jul 8 01:47 3-gene._usr_local.1 -rw--- 1 amanda disk 491520 Jul 8 01:47 3.gene._usr_local.1 [...] -rw--- 1 amanda disk 10 Jul 8 03:07 00040-coyote._bin.1 -rw--- 1 amanda disk 65536 Jul 8 03:07 00040.coyote._bin.1 -rw--- 1 amanda disk 10 Jul 8 03:07 00041-coyote._usr_man.1 -rw--- 1 amanda disk 65536 Jul 8 03:07 00041.coyote._usr_man.1 -rw--- 1 amanda disk 10 Jul 8 03:08 00042-coyote._usr_movies.1 -rw--- 1 amanda disk 65536 Jul 8 03:08 00042.coyote._usr_movies.1 -rw--- 1 amanda disk 10 Jul 8 03:08 00043-coyote._dos.1 -rw--- 1 amanda disk 65536 Jul 8 03:08 00043.coyote._dos.1 -rw--- 1 amanda disk 10 Jul 8 03:08 00044-TAPEEND -rw--- 1 amanda disk 32768 Jul 8 03:08 00044.TAPEEND -rw-r--r-- 1 amanda disk 71680 Jul 8 03:09 configuration.tar -rw-r--r-- 1 amanda disk 95344640 Jul 8 03:09 indices.tar In the event of an error that isn't caused by the disk itself turning tits up, tar gzip can recover the contents of any of them. Amanda in that case is a luxury. The last 2 files are my own bit of cma as they represent the config dir that generated these vtapes, and the complete, uptodate indices for the whole system as it exists for the current tapelist. From those and the /home dir, which contains the srcs for the last several versions of amanda-2.4.5, if I had to do a bare metal, I'd get the /home/amanda tree, install the latest amanda, then tar gzip the last 2 files back to their original locations. From there I ought to be able to start an amrestore and goto bed. It seems easier and safer to to just have amverify buffer the error and if it is successful in reading the DLE from the next tape don't output the error.
Antw: Re: Problems with amverifyrun
Hi guys, taking the following two statements: Seems to me that your desired behavior would be reasonable. Agreed, safety and time make it undesireable to my thinking. I have to conclude: 1) The current behaviour is normal and more or less intended. ;-) 2) At the moment there is no amanda inherent solution to my problem. 3) My wish concerning error reporting is not too strange. So my question now: Is there an solution in sight or can it be implemented? Thanks for all answers. Best regards Andreas
Re: Problems with amverifyrun
Gene: To me, the obvious cure would be to remove the partial file Frank: This seems dangerous to me. It seems easier and safer to to just have amverify buffer the error and if it is successful in reading the DLE from the next tape don't output the error. Gene: Which makes perfect sense to me. And, it shouldn't take more than say 10-15 lines of code to do it. I agree that this should be solved in amverify(run). I really like the idea of limiting write-access to (v)tapes to amdump. After the dumps have been done, successfully or hitting EOT, the rest should be read-only and errors covered by the binaries accessing the (v)tapes. Following this principle seems to reduce risk to me. Stefan -- Stefan G. Weichinger AMANDA core team member mailto://[EMAIL PROTECTED] -- oops! linux consulting implementation http://www.oops.co.at --
Re: Problems with amverifyrun
On Fri, Jul 08, 2005 at 11:03:34PM +0200, Stefan G. Weichinger wrote: Gene: To me, the obvious cure would be to remove the partial file Frank: This seems dangerous to me. It seems easier and safer to to just have amverify buffer the error and if it is successful in reading the DLE from the next tape don't output the error. Gene: Which makes perfect sense to me. And, it shouldn't take more than say 10-15 lines of code to do it. I agree that this should be solved in amverify(run). I really like the idea of limiting write-access to (v)tapes to amdump. After the dumps have been done, successfully or hitting EOT, the rest should be read-only and errors covered by the binaries accessing the (v)tapes. Following this principle seems to reduce risk to me. Particularly as (to my knowledge) amverify does no tape writing at the present time. It would add an entire new, major set of routines. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Antw: Re: Problems with amverifyrun
On Fri, Jul 08, 2005 at 10:47:25PM +0200, MATILDA MATILDA wrote: Hi guys, taking the following two statements: Seems to me that your desired behavior would be reasonable. Agreed, safety and time make it undesireable to my thinking. I have to conclude: 1) The current behaviour is normal and more or less intended. ;-) I'd not say 'intended'. More like most sites only use a single tape for each run and lots of sites don't use amverify regularly. Together that means not a lot of sites have hit the problem and none to date reported it as a complaint. 2) At the moment there is no amanda inherent solution to my problem. Think that is correct. 3) My wish concerning error reporting is not too strange. Not at all. So my question now: Is there an solution in sight or can it be implemented? Soon as you or someone else takes an interest to change the code. Either tomorrow or sometime next year :) As Stefan so often says APAW. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Antw: Re: Problems with amverifyrun
Jon LaBadie wrote: Soon as you or someone else takes an interest to change the code. Either tomorrow or sometime next year :) As Stefan so often says APAW. Hey! This is your acronym, Jon ;-)) -- Stefan G. Weichinger AMANDA core team member mailto://[EMAIL PROTECTED] -- oops! linux consulting implementation http://www.oops.co.at --
Re: Antw: Re: Problems with amverifyrun
On Friday 08 July 2005 16:47, MATILDA MATILDA wrote: Hi guys, taking the following two statements: Seems to me that your desired behavior would be reasonable. Agreed, safety and time make it undesireable to my thinking. I have to conclude: 1) The current behaviour is normal and more or less intended. ;-) 2) At the moment there is no amanda inherent solution to my problem. 3) My wish concerning error reporting is not too strange. So my question now: Is there an solution in sight or can it be implemented? I'm not an amanda coder. Now that we've got that out of the way, I have in the past 30 or so years, written some code. Based on that, it does seem to me that its a solvable problem, either by fixing amverify, or amdump to not write the I know its gonna be short and incomplete file in the first place. In the interests of time efficiency, I'd vote for the latter solution if given the choice. Thanks for all answers. Best regards Andreas -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
