Re: amrestore problem, headers ok but no data
Stefan, On Wed, Jan 19, 2005 at 10:48:54PM +0100, Stefan G. Weichinger wrote: BC Major imporvement though still below the acceptable threshold. BC Definitely looking like it was never an amanda issue, this looks to BC be an underlying architecture problem. I hope that you spot the issue soon, sounds much better already ;-) Always the simple stuff. Block size (still need to find out how to reset at boot time), SCSI bus length... Confirmed with SGI engineer, with the Narrow device on the bus we are limited to 1.5 meters, we'd have been ok with WIDE devices, 3 Meter limit but we are clearly over. Will see if I can't get permission to remove SDLT/shoebox and see if the jukebox doesn't work properly. In the longer term I think we've convinced the machine owner to purchase/install an additional SCSI card. thank you, Brian --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amrestore problem, headers ok but no data
On Friday 21 January 2005 11:37, Brian Cuttler wrote: Stefan, On Wed, Jan 19, 2005 at 10:48:54PM +0100, Stefan G. Weichinger wrote: BC Major imporvement though still below the acceptable threshold. BC Definitely looking like it was never an amanda issue, this looks to BC be an underlying architecture problem. I hope that you spot the issue soon, sounds much better already ;-) Always the simple stuff. Block size (still need to find out how to reset at boot time), SCSI bus length... Put the appropriate commands, as you would exec them from a root shell, in the /etc/rc.d/rc.local file. They'll work as long as there is a loaded tape in the drive during the bootup. Confirmed with SGI engineer, with the Narrow device on the bus we are limited to 1.5 meters, we'd have been ok with WIDE devices, 3 Meter limit but we are clearly over. What??? Is??? He??? Smoking??? I want some of that! Its got to be great stuff... The scsi bus, properly setup and terminated, can be as long as 30 some meters, and I have personally ran it well over 10 feet! But with poorly matched stuff, you are often in the virgin sacrificing business at 18 inches or less. This 'engineer' (note the lowercase, its intended) obviously does not understand that the scsi bus is a transmission line, and subject to the usual rules regarding control of vswr. VSWR=Voltage Standing Wave Ratio, and is a measure of the raltive magnitudes of the signal power going down the cable, and coming back up the cable from the far end. Ideally, with proper terms in place, there is no echo from either end as the terms perfectly absorb the signal by presenting a load to the cable that matches the cables impedance very closely, making the cable look to be of almost infinite length. The bus itself is wired OR, open collector style, meaning that any device, anyplace on the bus, can exert a pulldown to a logic zero, and thos signal will propagate both ways on the cable from a device in the middle, with no echo's comeing back from either end of the cable under ideal conditions. In order to control echos or vswr as the rf folks call it, it must be terminated with its characteristic impedance at both ends of the cable. Note that this means the extra lines for a wide bus MUST be terminated at the physical end of that wider portion of the bus, preferably with whats known as an active termination as that typically matches the cables impedance much better than the usual powered resistor packages do. Then the rest of the cable, the narrow part, needs to be terminated at its physical ends too, with no spare cable going on by that point because of the echos generated by the open end of the cable if the terms are not actually at the end of the path. The card normally terminates the src end of the cable, usually with active terms today, but its toss a coin to see what you get from the aftermarket folks unless you specify, and accept and pay for, no less. Let me get a view of what your logic one noise margin is Brian, grab a multimeter and poke into an unused connector of the cable and read the resting voltages of 3 or 4 of the lines and tell me what your meter reads please. All lines on one side of the connector should be grounded, so I'm interested in the 2.x volts you'll read on the other lines. Will see if I can't get permission to remove SDLT/shoebox and see if the jukebox doesn't work properly. In the longer term I think we've convinced the machine owner to purchase/install an additional SCSI card. They aren't THAT expensive, but non-technical bean counters often cannot see the value obtained from the expense spent because they don't understand the value received is often a do, or don't, and there is no middle ground scenario. You often have to explain it in terms of if you want it to work, we spend x dollars to make it work. Otherwise its no workee. Then its simple. Give them a middle ground where it might work, and they'll assume you walk on water and can make it work everytime. We're quite often not that lucky in this business. Worth every penny in most cases. Good luck. -- Cheers Brian, 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.32% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: amrestore problem, headers ok but no data
Info update only. Ok we've shutdown the Origin 300 and swapped the scsi daisy-chain around a little. At this point the SDLT in the shoebox was able to restore a large tar file without causing a SCSI reset and hanging the system. I then set the blocksize on the SDLT in the jukebox and relabled the amanda tapes. I ran an amdump with only 3 DLE, one using dump and 2 using (gnu)tar. As always, the amdump completed with (apparent) success. This time however I was actually able to restore the dump file (a relatively small level 1), and partitially restored both tar dumps before they each hung the bus and caused a reset. My hope is that the (NARROW) robot is still between the SDLT in the jukebox and that swapping the scsi cable and the terminator on the jukebox will resolve the issue. I'm waiting on the vendor of the jukebox on this info - if I don't hear quickly I'll just open the cover on the jukebox and have a look inside. Major imporvement though still below the acceptable threshold. Definitely looking like it was never an amanda issue, this looks to be an underlying architecture problem. --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amrestore problem, headers ok but no data
Hi, Brian, on Mittwoch, 19. Jänner 2005 at 22:02 you wrote to amanda-users: BC Major imporvement though still below the acceptable threshold. BC Definitely looking like it was never an amanda issue, this looks to BC be an underlying architecture problem. I hope that you spot the issue soon, sounds much better already ;-) -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: amrestore problem, headers ok but no data
On Tuesday 11 January 2005 16:40, Jon LaBadie wrote: Also, I think that if both types of devices exist on the same bus, the lower performance one determines the performance of the entire bus. In theory, this is *not* the case. One of the (many) selling points of SCSI over IDE is supposed to be that a SCSI bus can run each device at its own speed (though perhaps later versions of the IDE spec have caught up, as they have in some other respects; I dunno). Of course, the slower/narrower device will consume more of the SCSI bus's available bandwidth to carry the same amount of data, even if they don't directly affect performance of the faster/wider devices. In practice, according to the excellent SCSI FAQ, it depends on the devices in question. See these questions in particular: - Can I connect a SCSI-3 disk to my SCSI-1 host adapter? [...] (which isn't Brian's precise situation, but the answer might well apply) - How can I calculate the performance I'll get with mixed SCSI devices? The SCSI FAQ is dated, but still useful. It's at www.scsifaq.org; click on the link for Official comp.periphs.scsi FAQ. Sorry, but the site uses too-smart-for-its-own-good navigation that makes it hard to post the actual URL. On Tue, Jan 11, 2005 at 10:48:17PM -0500, Gene Heskett wrote: [A SCSI bus is] double handicapped because the cable is, compared to a piece of well built coax, pretty much a guestimate as to its operating impedance, usually quoted as being in the 120 to 130 ohm territory, This isn't supposed to be a problem either, because cable impedence isn't supposed to be a guesstimate; it's explicitly specified in the SCSI specs. But in practice, what you've said is true; there's all manner of out-of-spec junk sold as SCSI cables. For example, I've read that you can have problems if you put a SCSI adapter in the middle of an internal/external chain, even if all the termination is correct, because the internal ribbon cable and the external cable might have different impedences, leading to signal reflections between the two cables. For a telling, if rather ancient, anecdote told by someone from Adaptec, see question What is the problem with the Adaptec 1542C and external cables? in the SCSI FAQ. off-topic To many folks forget that a a scsi bus is indeed an rf transmission line, subject to the usual rules about vswr. Geez, you mean we've got an actual engineer in the e-room? Awesome! (Despite my rambling about impedences and such, I'm sure no hardware guy.) From the context it's pretty clear what vswr means, but what does it stand for? /off-topic -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / In theory, there is no difference between theory and practice. But, in practice, there is. - Jan van de Snepscheut
Re: amrestore problem, headers ok but no data
On Wed, Jan 12, 2005 at 11:18:00AM -0500, Eric Siegerman wrote: On Tuesday 11 January 2005 16:40, Jon LaBadie wrote: Also, I think that if both types of devices exist on the same bus, the lower performance one determines the performance of the entire bus. In theory, this is *not* the case. ... On Tue, Jan 11, 2005 at 10:48:17PM -0500, Gene Heskett wrote: As to the whole chain being restricted to the speed of the slowest device, I've heard that, but it doesn't, on the face of it, make a lot of sense to me Gene, Eric, Thanks for the correction. I'm glad I remembered to say I wasn't a scsi expert. My comments provide the proof. off-topic To many folks forget that a a scsi bus is indeed an rf transmission line, subject to the usual rules about vswr. From the context it's pretty clear what vswr means, but what does it stand for? /off-topic Wondered too, as I'm posting anyway, I'll guess: v??? standing wave reflections jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amrestore problem, headers ok but no data
Google says: voltage standing wave ratio To many folks forget that a a scsi bus is indeed an rf transmission line, subject to the usual rules about vswr. From the context it's pretty clear what vswr means, but what does it stand for? /off-topic Wondered too, as I'm posting anyway, I'll guess: v??? standing wave reflections jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax) -- _ Joe Lewandoski, N342, x85722 jlwndski at bellsouth dot net lewandoskij at navo dot navy dot mil
Re: amrestore problem, headers ok but no data
On Wednesday 12 January 2005 14:55, Gene Heskett wrote: On Wednesday 12 January 2005 12:04, Jon LaBadie wrote: On Wed, Jan 12, 2005 at 11:18:00AM -0500, Eric Siegerman wrote: On Tuesday 11 January 2005 16:40, Jon LaBadie wrote: Also, I think that if both types of devices exist on the same bus, the lower performance one determines the performance of the entire bus. In theory, this is *not* the case. ... On Tue, Jan 11, 2005 at 10:48:17PM -0500, Gene Heskett wrote: As to the whole chain being restricted to the speed of the slowest device, I've heard that, but it doesn't, on the face of it, make a lot of sense to me Gene, Eric, Thanks for the correction. I'm glad I remembered to say I wasn't a scsi expert. My comments provide the proof. off-topic To many folks forget that a a scsi bus is indeed an rf transmission line, subject to the usual rules about vswr. From the context it's pretty clear what vswr means, but what does it stand for? /off-topic Wondered too, as I'm posting anyway, I'll guess: v??? standing wave reflections VSWR=Voltage Standing Wave Reflections. Back in rf days, because the signal is repetitive, very high voltages could develop at certain points in a transmission line driving an antenna that wasn't an ideal load, so they came to be known as standing waves. And it doesn't take a lot of miss-match to burn a 6 1/8 75 ohm rigid copper coax with 30kw peak power going into it at channel 19 (about 507mhz), making you call in a tower crew and replace the burnt section and clean the teflon carbon out of the other 1000 feet of it. Lets just say thats expen$ive... But now lets get down to the much profaned scsi buss, where these same physical laws apply even if they don't make junk and smoke out of expensive copper and teflon parts. Understand we are dealing with a bus capable of responding to a 10 nanosecond or less signal for starters, often lots less. Some ascii art if you'll all bear with me use a monospaced font. The vertical scale: 3.0 Volts a solid logic 1 2.4 Volts unk upper bound, usually a 1 99% of the time 1.8 Volts unk logic state 1.2 Volts unk logic state 0.6 Volts unk lower bound, usually a 0 99% of the time 0.0 Volts a solid logic zero Now assume a worst case condition of no termination just to make it simple. Input pulse from typical wired-or driver, active pulldown. And screw it, the (insert 15 minute non-repetitive monologue of swearing) list server ate my tabs. Sorry folks, I tried. t0 t+5ns t+10ns t+15ns t+20ns t+25ns t+30ns 1---| | ? | | ? | | ? | | ? | | 0 | Same pulse 18 down the cable after the pulse has reached the end of the 24 cable and bounced because its not terminated. |-| - this could be clipped | | | |-| | | | | | | | |- | | | | |etc | |-| | | | |etc | | | | | |etc | | | | | |etc | | | | | | | | | |-|etc | | | | | |-| | |---| As you can see, after the main data pulse, there are several forays into unknown territory as the rest of the circuit slowly absorbs the unwanted echo. Also, in the real world, there would be some wibbles in the initial logic zero time I drew as a flat line, but most of these are absorbed by the very solidly turned on driver transistor at the time. These largly disappear if the terminations are correct, but only active terms really match the cable that well. This loss of the upper boundary noise margin in particular is one of the reasons I'd love to see a special, 5.8 volt supply made available just for supplying term power to scsi busses, the extra .8 volts to make up for the losses because the average card designer gets his choice of a low voltage drop schotkey diode for the isolator overridden by some friggin bean counter who doesn't understand that his arbitrary replacement of a 50 cent diode with a 10 cent si diode, and its .7 volt loss, has just cost the product about 90% of its logic 1 noise margin by reducing the upoper resting voltage of the buss to the 2.6 volt area. And we wind up advertising for virgins to sacrifice to make the darned thing work. Hell, even a Ge diode would be a better choice if they think they cannot afford that 50 cent schotkey. Hopefully this poor ascii art might clarify the situation a bit. If I'm curious, I turn on my scope and look, but TBT, my 100 mhz dual trace scope is actually a bit slow to really display stuff like this. Stuff like this really needs a 500mhz scope to display it anywhere near in real time, but the chips on a scsi buss are in fact that fast! -- 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.31% setiathome rank, not
Re: amrestore problem, headers ok but no data
Hi, Jon, on Montag, 10. Jänner 2005 at 22:19 you wrote to amanda-users: JL In recent versions, amanda can work with blocksizes other than 32k. JL I forget if it is a configure option needed during the build or JL a parameter that can be set in amanda.conf. I've never used it. The parameter blocksize goes into the tapetype-section in amanda.conf. man amanda says about that parameter: blocksize int Default: 32 kbytes. How much data will be written in each tape record. The minimum blocksize value is 32 KBytes. The maximum blocksize value is 32 KBytes. The maximum is set during configure with --with-maxtapeblocksize. Maybe this is just documented wrong, as the minimum is the same as the maximum, except when you set another maximum with the configure-option. But as I see from the other thread, Brian is on another path right now ... maybe he'll come back to blocksizes later. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: amrestore problem, headers ok but no data
Amanda user list, I've spoken to Harry at Condre systems and he confirmed what we where seeing. The jukebox robot is a narrow bus so that are two changes we need to make. 1) We want to move the jukebox/SDLT to be the last device on the daisy chain. 2) We want to terminate the jukebox-robot, so we need to make certain that the live port on the box hits the SDLT before we reach (electically) the robot. Hopefully this will have a positive effect on both SDLT drives. --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amrestore problem, headers ok but no data
Jon, Recommended buying an additional scsi card more than once to the system's owners, haven't made the case yet (maybe now). I would really have liked the raid array on a separate bus from the tape drives. I have to trust that the proper cabeling to terminate the additional lines is present in the jukebox casing as the wiring is inaccessible and the sdlt completely enclosed (there is a door that slides open to admit to expel cartridges) and only well, 4 connection, 2 scsi (in and out), power and a port for a serial console. I agree with you completely but all I can hope for at the moment is to get the narrowest bus as far away from the cpu as I can. thanks, Brian On Tue, Jan 11, 2005 at 04:40:40PM -0500, Jon LaBadie wrote: Not a scsi expert here, but if you terminate the jukebox, wouldn't that terminate only the narrow portion of the bus leaving the extra lines of the wide bus unterminated. Might there be some kind of device/cable to go from wide - narrow terminating the unused lines? Also, I think that if both types of devices exist on the same bus, the lower performance one determines the performance of the entire bus. That narrow jukebox may hurt your sdlt performance just by being on the bus. Some of my scsi adapters have multiple channels and buses. Perhaps you could run the sdlt's on one channel, wide, and the jukebox on another, narrow or wide. I added a cheap second controller from a dead system for a very similar purpose, external devices that were narrow when the main controller was driving only wide devices. Its two channels were used for different speed devices. jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax) --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amrestore problem, headers ok but no data
On Tuesday 11 January 2005 16:40, Jon LaBadie wrote: On Tue, Jan 11, 2005 at 03:40:47PM -0500, Brian Cuttler wrote: Amanda user list, I've spoken to Harry at Condre systems and he confirmed what we where seeing. The jukebox robot is a narrow bus so that are two changes we need to make. 1) We want to move the jukebox/SDLT to be the last device on the daisy chain. 2) We want to terminate the jukebox-robot, so we need to make certain that the live port on the box hits the SDLT before we reach (electically) the robot. Hopefully this will have a positive effect on both SDLT drives. Not a scsi expert here, but if you terminate the jukebox, wouldn't that terminate only the narrow portion of the bus leaving the extra lines of the wide bus unterminated. Might there be some kind of device/cable to go from wide - narrow terminating the unused lines? Also, I think that if both types of devices exist on the same bus, the lower performance one determines the performance of the entire bus. That narrow jukebox may hurt your sdlt performance just by being on the bus. Some of my scsi adapters have multiple channels and buses. Perhaps you could run the sdlt's on one channel, wide, and the jukebox on another, narrow or wide. I added a cheap second controller from a dead system for a very similar purpose, external devices that were narrow when the main controller was driving only wide devices. Its two channels were used for different speed devices. jl Generally speaking Jon, thats very good advice. In any event, where there is a transition to narrow devices, the unused lines must be properly terminated. To many folks forget that a a scsi bus is indeed an rf transmission line, subject to the usual rules about vswr. And double handicapped because the cable is, compared to a piece of well built coax, pretty much a guestimate as to its operating impedance, usually quoted as being in the 120 to 130 ohm territory, hence the commonly used resistive termination of a pair of resistors attached to the data line, a 220 ohm connected to the +5 volt line, and a 330 ohm connected to ground. It works quite well provided the resting voltage on the data lines can be held well above the 2.6 volt region, preferably at nearly 3.0 volts, giving an equal noise margin for both a logic zero and a logic one. Having that isolation diode in series with this feed often drops that voltage into the very low noise margin region below 2.6 volts. At that point you start sacrificing virgins etc to make it work. As to the whole chain being restricted to the speed of the slowest device, I've heard that, but it doesn't, on the face of it, make a lot of sense to me given that the drivers are properly written to auto-detect whats narrow and slow, and whats wide and fast. But thats a given I wouldn't swear about, at maybe... Driver quality does vary unfortunately depending on the authors whims and expertise at the time. If Brian has an old card he can stick in just to run the robot, it sure would be worth the try. -- 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.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Re: amrestore problem, headers ok but no data
The following (just scripted, with commentary added) is a little long and rather un-good. samar 9# script Script started, file is typescript Position us at the start of the next volume. This volume has been relabeled after setting the block size on the tape (last week). samar 1# /usr/local/sbin/amcheck samar Amanda Tape Server Host Check - ERROR: holding disk /usr5/dumps/amanda: statfs: No such file or directory amcheck-server: slot 7: date Xlabel SAMAR08 (exact label match) NOTE: skipping tape-writable test Tape SAMAR08 label ok Server check took 4.311 seconds Amanda Backup Client Hosts Check Client check: 1 host checked in 0.168 seconds, 0 problems found (brought to you by Amanda 2.4.4p1-20030716) Find out the current block size. I has expected 32768, it isn't. samar 2# mt -f /dev/sdlt2 blksize Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: Variable Get the current label. We failed unless we specified the blocksize of 32768. samar 5# mt -f /dev/sdlt2 rewind samar 2# dd if=/dev/sdlt2 of=./scratch Read error: Invalid argument 0+0 records in 0+0 records out samar 3# dd if=/dev/sdlt2 of=./scratch bs=32768 1+0 records in 1+0 records out Many null characters removed from cat output. samar 6# dd if=/dev/sdlt2 of=./scratch bs=32768 1+0 records in 1+0 records out samar 7# cat -evt scratch | more AMANDA: TAPESTART DATE X TAPE SAMAR08$ ^L$ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@^@ Set the blocksize to the drive recommended size. samar 8# mt -f /dev/sdlt2 setblksz 131072 samar 9# dd if=./scratch of=/dev/sdlt2 obs 131072 Bad argument: obs samar 10# dd if=./scratch of=/dev/sdlt2 obs=131072 Write error: Invalid argument 64+0 records in 0+0 records out samar 11# mt -f /dev/sdlt2 blksize Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: 131072 byte(s) samar 12# dd if=/dev/sdlt2 of=./scratch bs=131072 0+0 records in 0+0 records out samar 13# mt -f /dev/sdlt2 rewind samar 14# dd if=/dev/sdlt2 of=./scratch bs=131072 0+0 records in 0+0 records out samar 15# !cat cat -evt scratch | more samar 16# mt -f /dev/sdlt2 rewind samar 17# dd if=/dev/sdlt2 of=./scratch bs=131072 0+0 records in 0+0 records out samar 18# /usr/local/sbin/amcheck samar Amanda Tape Server Host Check - ERROR: holding disk /usr5/dumps/amanda: statfs: No such file or directory amcheck-server: slot 7: reading label: Invalid argument amcheck-server: slot 8: reading label: Invalid argument Progressed this way through the rest of the tapes. - use amtape to reset us to slot 7. Probing the drive I find a block size of 32768 again. samar 25# mt -f /dev/sdlt2 setblksz 131072 samar 26# /usr/local/sbin/amlabel -f samar SAMAR08 labeling tape in slot 7 (/dev/sdlt2): rewinding, reading label, reading label: Invalid argument rewinding, writing label SAMAR08 amlabel: writing label: Invalid argument Have we hit some sort of amanda buffer size limit ? Something that didn't error during the write but did during the read ? Are the new drivers in the OS failing to properly handle the drive ? My money is on an OS problem. Is anyone successfully using SDLT 320 drives on an SGI/IRIX system ? Note, I have the required APD drivers installed and configured. I'm gonna open a call with SGI. Jan 10 10:58:54 3D:samar TapeCheckError[234379]: |$(409)tps1d4,SDLT320,,pid=411237,read,Aborted command,IDE message received Jan 10 10:58:54 6D:samar tps1d4[234379]: Command aborted by target -- Jan 10 10:58:54 3D:samar tps1d4[234379]: Aborted command --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amrestore problem, headers ok but no data
On Mon, Jan 10, 2005 at 11:48:42AM -0500, Brian Cuttler wrote: The following (just scripted, with commentary added) is a little long and rather un-good. ... Probing the drive I find a block size of 32768 again. samar 25# mt -f /dev/sdlt2 setblksz 131072 samar 26# /usr/local/sbin/amlabel -f samar SAMAR08 labeling tape in slot 7 (/dev/sdlt2): rewinding, reading label, reading label: Invalid argument rewinding, writing label SAMAR08 amlabel: writing label: Invalid argument Have we hit some sort of amanda buffer size limit ? Something that didn't error during the write but did during the read ? This is not too surprising to me. A tape with a blocksize of 132k will accept a write of 32k and simply pad it to the required size. No errors. But on read back, it will not allow a read of 32k when the blocksize of the taped data is 132k. That could be your read error. In recent versions, amanda can work with blocksizes other than 32k. I forget if it is a configure option needed during the build or a parameter that can be set in amanda.conf. I've never used it. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amrestore problem, headers ok but no data
Jon, On Mon, Jan 10, 2005 at 04:19:45PM -0500, Jon LaBadie wrote: Something that didn't error during the write but did during the read ? This is not too surprising to me. A tape with a blocksize of 132k will accept a write of 32k and simply pad it to the required size. No errors. But on read back, it will not allow a read of 32k when the blocksize of the taped data is 132k. That could be your read error. In recent versions, amanda can work with blocksizes other than 32k. I forget if it is a configure option needed during the build or a parameter that can be set in amanda.conf. I've never used it. It has been an eventful afternoon. I'll try to get a newer version installed tomorrow. I just learned that I have have a device ordering problem on the scsi chain. Looks like the robot may be interfering with my second sdlt in the shoebox. Though I don't expect it to be causing a problem with the sdlt within the robot case. samar 39# scsiha -t -p 1 BUS PARMS: Selection Timeout: 25 uS, Host SCSI ID: 0, SE TARGET PARMS: [1] async. transfers, NARROW : [2] sync. period: 50 nS, sync. offset: 14, WIDE : [4] sync. period: 50 nS, sync. offset: 14, WIDE : [5] sync. period: 50 nS, sync. offset: 14, WIDE --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amrestore problem, headers ok but no data
On Fri, Jan 07, 2005 at 03:11:41PM -0500, Jon LaBadie wrote: That ENOMEM, reported as insufficient memory sometimes used to throw me for a loop. Here is the situation as I understand it. To enhance performance dd tries to do unbuffered I/O, meaning the data goes directly to memory in dd rather than through buffers in the OS and then to dd. An upshot of this is that the buffer dd reads into must be at least as big as a block on the device. As there is no OS buffering, dd must get the entire block from the device in one shot, no taking little chunks at a time. The devices do not send bytes on request, they send blocks. This is correct, except for one minor quibble -- the claim that dd *tries* to do unbuffered I/O. As I understand it, dd has no choice in the matter. Character devices (usually?) behave as you've described: there's no buffering within the kernel; the data flows more-or-less directly from the hardware into the process's user-space buffer, and vice versa during writes. Further, each read() or write() call by the process is typically translated into a single hardware I/O request. This imposes a restriction on the user process: the call must read and write only whole hardware blocks. Specifically: (a) each read() or write() call must start on a block boundary (b) it must also end on a block boundary For character, aka raw, disk devices, the read() and write() cases are identical: (a) at the time of any read() or write() call, the seek offset must be a multiple of the disk's sector size (b) the requested length must (typically?) be a multiple of the same When writing to a traditional, variable-length tape device, each write() call writes exactly one physical block to the tape: (a) the new block starts wherever the head was positioned at the time, or somewhere after that if the drive had to skip past a bad spot on the tape (b) the length of the new block is precisely the length passed to write() When reading from such a tape device, each read() call reads exactly one physical block from the tape: (a) at the start of the call, the heads are guaranteed *not* to be positioned in the middle of a block; they might be precisely at the start of the next block to be read, or there might first be a bad spot in the tape to be skipped over, which doesn't contain any data. The hardware enforces this constraint, perhaps with help from the driver. Unlike disk devices, tape devices aren't seekable; thus the user code has no way to position the tape incorrectly. (Skipping backwards and forwards is always done in whole blocks -- hence the names, backward/forward skip *record*.) (b) the read buffer must be at least large enough to contain the entire block. The (single) block will be read in its entirety, and its actual length returned by read(). Block devices are a different story; they go through the buffer cache, the same as regular disk files do, so none of the above restrictions apply. The cost of that convenience is lower performance; the kernel breaks up large read() and write() calls into cache-buffer-sized chunks, so you might have to wait almost an entire disk rotation for each sector, whereas with the character device, you'd only have to pay that cost once for the entire read() or write() call. (Roughly analogous to shoeshining a tape drive vs. letting it stream :-)) (I think Linux is a bit weird in this respect; its disk special files are block devices, but seem to behave more like character devices. Let me be perfectly clear: I don't know this for sure. I'm inferring it from Linus's claim that dump can't get a consistent view of a Linux file system. If Linux's block disk devices *acted* like block devices, AFAICT his claim would have to be false. But the claim must be true -- I mean, if anyone knows, it's Linus, right? Hence the initial assumption must be false. QED. (His more general dissing of dump isn't fact, it's opinion, and so has no bearing here.)) I remember once -- probably back in V6 days -- seeing a UNIX with both block and character special files for tapes. That is, each drive had (at least) all of these variants: rewinding non-rewinding - - block /dev/mt0/dev/nmt0 character /dev/rmt0 /dev/nrmt0 The character version of a tape device worked as described above. The block version went through the buffer cache like any other block device, which resulted in tapes with 512-byte blocks, no matter how much you write()ed -- uh, wrote()? :-) -- in one call. That'd waste a *lot* of tape; it's not surprising that I haven't seen a block-special file for a tape in a very long time. The only optimization that's left for dd to perform is a small one: if ibs and obs are the same, it can save a tiny amount of CPU time by not using an inner loop; it can just do something like this
Re: amrestore problem, headers ok but no data
Apologies for following up my own post. On Sat, Jan 08, 2005 at 06:20:59PM -0500, Eric Siegerman wrote: [...] in neither case does [dd] need to copy the data from one buffer to another. It can just have a single buffer that's max(ibs,obs) long [...] Oops; I'm wrong about this. It's only true if ibs is an exact multiple of obs, or vice versa. Otherwise, the data *will* need to be copied. I have no idea whether any dd implementations do in fact optimize the exact-multiple case. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The animal that coils in a circle is the serpent; that's why so many cults and myths of the serpent exist, because it's hard to represent the return of the sun by the coiling of a hippopotamus. - Umberto Eco, Foucault's Pendulum
Re: amrestore problem, headers ok but no data
Hello, Brian, I thought of your problems this morning ;-) Just now (on 01/07/2005 at 17:17) you wrote: BC Oddly trying to dd if=/dev/rmt/tps... read no data BC samar 85# mt -f /dev/rmt/tps1d4nrns rewind BC samar 86# dd if=/dev/rmt/tps1d4nrns of=scratch BC Read error: Invalid argument Invalid argument ! Gene wrote: GH Then you can use a GH #dd if=/path/to/device of=scratch count=1 Notice the option count, dd has to be told how much to read/write ... BC However, I ran amdump last night. Still having problems with TAR DLE BC though oddly I was able to see that a DUMP DLE attempted to write. BC I was able to retrieve the file, using both amrestore and Eric's BC suggestion of manually issuing the dd command to get the file from BC tape. I was able to open the dump file (DLE for /usr1) and saw that BC the file kmitra was present. This I thought to be good news since BC the only top level file on the partition is kmitra/ (note directlry BC slash). Unfortuantely xfsdump reported the file as a regular file BC and not a directory and I was unable to proceed from there. Do your AMANDA-binaries point to the proper xfs-tools? Is the proper xfsdump used? BC I've tried to retrieve several of the TAR DLE but have been unsuccessful BC with either method. BC On the issue of streaming the drive vs horsepower. We have a holding BC disk (unlike a few early runs of this config) and we seem to dump to BC tape quickly enough once the dumper portion completes. I don't know that BC we are polishing the tape. BC Something very basic is wrong, looks like the 15th config is the BC unlucky one. What about setting up a second config on this host, with just one small DLE and a few tapes for testing? Maybe you can dig things up with this. And BTW: could you please try to strip the older mails from your replies to save bandwidth, your last mail was about 26k in size, with only a few new lines in it. Thank you. -- Best regards, Stefan
Re: amrestore problem, headers ok but no data
Stefan, Yes, will strip more stuff out (didn't realize it had grown so much. The instruction I was following from Gene where pretty explicite (not that I follow all that well) and where intended to save the amanda header, reset the block count, restore the header and flush the buffers. Unfortunately I failed to retrieve the headers and the command was simple enough that I'm baffled at having incorrectly coded it, invalid argument, must be me. I'll try again. Do your AMANDA-binaries point to the proper xfs-tools? Is the proper xfsdump used? Truth be told, I'd have expected dump and restore to be in the same directory as one another, but this matches the config on other, working Irix amanda systems. samar 126# which xfsrestore /sbin/xfsrestore samar 127# which xfsdump /usr/sbin/xfsdump Yes, I can try a different config on the system, or for that matter just save/edit the disklist and amanda.conf, its not like I am likely to lose a working config. thanks, Brian --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amrestore problem, headers ok but no data
Hi, Brian, on Freitag, 07. Jänner 2005 at 17:59 you wrote to amanda-users: BC The instruction I was following from Gene where pretty explicite BC (not that I follow all that well) ;-) BC and where intended to save the BC amanda header, reset the block count, restore the header and flush BC the buffers. Unfortunately I failed to retrieve the headers and the BC command was simple enough that I'm baffled at having incorrectly BC coded it, invalid argument, must be me. I'll try again. Let's see. Do your AMANDA-binaries point to the proper xfs-tools? Is the proper xfsdump used? BC Truth be told, I'd have expected dump and restore to be in the same BC directory as one another, but this matches the config on other, working BC Irix amanda systems. BC samar 126# which xfsrestore BC /sbin/xfsrestore BC samar 127# which xfsdump BC /usr/sbin/xfsdump And these two binaries are found and used by the configure-script? BC Yes, I can try a different config on the system, or for that matter BC just save/edit the disklist and amanda.conf, its not like I am likely BC to lose a working config. I would do a copy to a second config and substitute the config-name where it has to be done (amanda.conf, the paths and stuff, you know that). Then you can fiddle around with that second config until you figure something out. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: amrestore problem, headers ok but no data
On Friday 07 January 2005 11:59, Brian Cuttler wrote: Stefan, Yes, will strip more stuff out (didn't realize it had grown so much. The instruction I was following from Gene where pretty explicite (not that I follow all that well) and where intended to save the amanda header, reset the block count, restore the header and flush the buffers. Unfortunately I failed to retrieve the headers and the command was simple enough that I'm baffled at having incorrectly coded it, invalid argument, must be me. I'll try again. Humm, are you saying that amlabel works and can read the label written, but that dd doesn't/cannot? Back to 'man dd' as it exists on that Irix system would be my next suggestion. Do your AMANDA-binaries point to the proper xfs-tools? Is the proper xfsdump used? Truth be told, I'd have expected dump and restore to be in the same directory as one another, but this matches the config on other, working Irix amanda systems. samar 126# which xfsrestore /sbin/xfsrestore samar 127# which xfsdump /usr/sbin/xfsdump Yes, I can try a different config on the system, or for that matter just save/edit the disklist and amanda.conf, its not like I am likely to lose a working config. thanks, Brian --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773 -- 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.31% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
Re: amrestore problem, headers ok but no data
Gene, Humm, are you saying that amlabel works and can read the label written, but that dd doesn't/cannot? Back to 'man dd' as it exists on that Irix system would be my next suggestion. Remembering that I'd set the blocksize on the device and relabeled yesterday I tried this. samar 160# mt -f /dev/sdlt2 rewind samar 161# dd of=/dev/sdlt2 bs=32k if=./scratch 1+0 records in 1+0 records out Which worked fine. I then tried to re-write the label with dd samar 170# dd of=/dev/sdlt2 obs=32k if=./scratch 64+0 records in 1+0 records out bs block size, obs outpub BS, (there is an IBS also, which I am afraid of developing should this not resolve soon) Actually the xfsrestore file is a link to the executable in the /usr/sbin directory. It does make sense, after a fashion (why not a link for the xfsdump executable as well). samar 126# which xfsrestore /sbin/xfsrestore samar 127# which xfsdump /usr/sbin/xfsdump I'm now going to attempt to run amdump with a much shorter disklist and see if I can't get a rational result on this tape. --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re[2]: amrestore problem, headers ok but no data
Hey Brian, just now (on 01/07/2005 at 19:20) you wrote: Humm, are you saying that amlabel works and can read the label written, but that dd doesn't/cannot? Back to 'man dd' as it exists on that Irix system would be my next suggestion. BC Remembering that I'd set the blocksize on the device and relabeled BC yesterday I tried this. BC samar 160# mt -f /dev/sdlt2 rewind BC samar 161# dd of=/dev/sdlt2 bs=32k if=./scratch BC 1+0 records in BC 1+0 records out BC Which worked fine. Good to hear. What size did scratch have? Much nicer device-name now, BTW, maybe this was the problem ... Do you use this one (the corresponding non-rewinding device) in amanda.conf as well ?? BC I then tried to re-write the label with dd BC samar 170# dd of=/dev/sdlt2 obs=32k if=./scratch BC 64+0 records in BC 1+0 records out Ok, I see, you had a bs=512 (0.5k) when you read and wrote the same file with bs=32k (64 times bigger now). BC Actually the xfsrestore file is a link to the executable in the /usr/sbin BC directory. It does make sense, after a fashion (why not a link for the BC xfsdump executable as well). samar 126# which xfsrestore /sbin/xfsrestore samar 127# which xfsdump /usr/sbin/xfsdump As long as AMANDA actually USES it this is OK, yes. BC I'm now going to attempt to run amdump with a much shorter disklist BC and see if I can't get a rational result on this tape. I am looking forward to the results ... Stefan
Re: amrestore problem, headers ok but no data
Stefan, Good to hear. What size did scratch have? Much nicer device-name now, BTW, maybe this was the problem ... Do you use this one (the corresponding non-rewinding device) in amanda.conf as well ?? I'll have to try to pull it again, I seem to have subsequently overwritten it with a zero length file. BC I then tried to re-write the label with dd BC samar 170# dd of=/dev/sdlt2 obs=32k if=./scratch BC 64+0 records in BC 1+0 records out Ok, I see, you had a bs=512 (0.5k) when you read and wrote the same file with bs=32k (64 times bigger now). BC Actually the xfsrestore file is a link to the executable in the /usr/sbin BC directory. It does make sense, after a fashion (why not a link for the BC xfsdump executable as well). samar 126# which xfsrestore /sbin/xfsrestore samar 127# which xfsdump /usr/sbin/xfsdump As long as AMANDA actually USES it this is OK, yes. I had intended (and forgot) to write, that I checked the amdump log file and that the paths and names of the programs are correct. I am looking forward to the results ... yah, me too. --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amrestore problem, headers ok but no data
On Fri, Jan 07, 2005 at 11:59:54AM -0500, Brian Cuttler wrote: samar 126# which xfsrestore /sbin/xfsrestore samar 127# which xfsdump /usr/sbin/xfsdump I suppose the theory must be that anyone can do a restore, but only root can use [xfs]dump. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The animal that coils in a circle is the serpent; that's why so many cults and myths of the serpent exist, because it's hard to represent the return of the sun by the coiling of a hippopotamus. - Umberto Eco, Foucault's Pendulum
Re: amrestore problem, headers ok but no data
On Fri, Jan 07, 2005 at 02:01:26PM -0500, Eric Siegerman wrote: On Fri, Jan 07, 2005 at 11:17:21AM -0500, Brian Cuttler wrote: samar 170# dd of=/dev/sdlt2 obs=32k if=./scratch 64+0 records in 1+0 records out bs block size, obs outpub BS, (there is an IBS also, which I am afraid of developing should this not resolve soon) bs is just a short cut to saying obs and ibs. So the following are the same: obs=32k ibs=32k bs=32k It is only necessary to use obs and ibs if they are different (including an unspecified one of the default 512 bytes). Oddly trying to dd if=/dev/rmt/tps... read no data samar 85# mt -f /dev/rmt/tps1d4nrns rewind samar 86# dd if=/dev/rmt/tps1d4nrns of=scratch Read error: Invalid argument 0+0 records in 0+0 records out These two things might well be related. That dd command, without a bs= argument, is trying to read 512-byte blocks. But the physical blocks on the tape are 32 KB -- your adjustments have seen to that. It would be appropriate for the read() call to fail in that situation, as indeed it did. On Solaris (whose man pages I have access to at the moment), the error status would be ENOMEM; perhaps on your system it's EINVAL == Invalid argument instead. (The place to look that up would likely be in the man page for the tape driver -- st(7) is where I found the Solaris version.) That ENOMEM, reported as insufficient memory sometimes used to throw me for a loop. Here is the situation as I understand it. To enhance performance dd tries to do unbuffered I/O, meaning the data goes directly to memory in dd rather than through buffers in the OS and then to dd. An upshot of this is that the buffer dd reads into must be at least as big as a block on the device. As there is no OS buffering, dd must get the entire block from the device in one shot, no taking little chunks at a time. The devices do not send bytes on request, they send blocks. So if dd is left with a default 512 byte ibs, input block size, but the device is using a larger block size, like an amanda tape of 32k, dd has allocated a 512 byte piece of memory to hold the input data. But when dd requests the first block it unexectedly gets 32k of data and has insufficient memory (ENOMEM). The reverse is not really a problem. Suppose you said ibs=128k. dd would simply read sufficient device blocks until the buffer was filled, four blocks in the above example. The problems arise when the device wants to feed dd more data per read than dd is prepared to receive. On output dd can make its own adjustments. If the obs is larger, it can move multiple input buffers to the output buffer before doing the write. If the reverse is true, input block size larger than output, it can copy part of the input block to the output buffer and do multiple outputs from a single input buffer. HTH jon -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amrestore problem, headers ok but no data
On Fri, Jan 07, 2005 at 01:20:42PM -0500, Brian Cuttler wrote: samar 170# dd of=/dev/sdlt2 obs=32k if=./scratch 64+0 records in 1+0 records out bs block size, obs outpub BS, (there is an IBS also, which I am afraid of developing should this not resolve soon) Yup, this makes sense. Since you specified obs, the input block size remained at the default of 512 bytes. dd read enough of those (64) to make a 32-KB output block and then wrote the latter. If the file had been longer, it would have repeated the process -- 64 512-byte reads followed by 1 32-KB write -- until done. It can also convert the other way, from a large ibs to a smaller obs. For a disk file, the block size doesn't matter much; things speed up if you use a larger one, but you get the same result except for dd's stats at the end. For a tape, block size can be a lot more important. With a traditional tape drive that uses variable-length blocks, each write() system call produces exactly one physical tape block, whose length is simply the length specified to write(). Correspondingly, each read() call reads exactly one physical tape block; the length specified to read() must be at least as large as the block currently under the heads, or something will go wrong (on Solaris SCSI tapes, as I mentioned before, the read will fail with ENOMEM; I don't know whether other systems behave differently, but one thing that almost certainly will *not* happen is that you get the first chunk of the physical block on this read(), and the next chunk on the next read(). One physical block for each read() call is the rule. This is why dd has separate ibs and obs arguments in the first place -- to let you reblock a tape, i.e. copy it to another tape while changing the block size, without making an intermediate copy on disk. When copying from one disk file to another, or between tape and disk, specifying different input and output block sizes doesn't really accomplish anything. I don't know how tape drives with fixed-length blocks (or configured for them, as in your case) work. Perhaps the drive does the necessary block-length conversion itself, using its internal RAM buffer. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The animal that coils in a circle is the serpent; that's why so many cults and myths of the serpent exist, because it's hard to represent the return of the sun by the coiling of a hippopotamus. - Umberto Eco, Foucault's Pendulum
Re: amrestore problem, headers ok but no data
samar 5# /usr/local/sbin/amrestore -r /dev/sdlt2 amrestore: 0: skipping start of tape: date 20050107 label SAMAR05 amrestore: 1: restoring samar._usr5_amanda.20050107.1 amrestore: read error: I/O error samar 6# mt -f /dev/sdlt2 rewind samar 7# mt -f /dev/sdlt2 fsf 1 samar 8# dd if=/dev/sdlt2 bs=32768 of=samar._usr5_amanda.20050107.1 skip=1 Read error: I/O error 1+0 records in 1+0 records out samar 9# mt -f /dev/sdlt2 rewind samar 10# mt -f /dev/sdlt2 fsf 1 samar 11# dd if=/dev/sdlt2 bs=32768 of=samar._usr5_amanda.20050107.1 Read error: I/O error 1+0 records in 1+0 records out samar 12# mt -f /dev/sdlt2 rewind samar 13# mt -f /dev/sdlt2 fsf 1 samar 14# cat -evt /dev/sdlt2 | more Input error: Invalid argument (/dev/sdlt2) samar 15# mt -f /dev/sdlt2 rewind samar 16# mt -f /dev/sdlt2 fsf 1 samar 17# dd if=/dev/sdlt2 bs=32768| cat -evt | more AMANDA: FILE 20050107 samar /usr5/amanda lev 1 comp .gz program /usr/local/sbin/ gnutar$ To restore, position tape at start of file and run:$ ^Idd if=tape bs=32k skip=1 | /usr/sbin/gzip -dc | usr/local/sbin/gnutar -f... -$ ^L$ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ ** many null characters removed. samar 18# mt -f /dev/sdlt2 rewind samar 19# mt -f /dev/sdlt2 fsf 1 samar 23# dd if=/dev/sdlt2 bs=32768 skip=1 | /usr/sbin/gzip -dc | /usr/local/sbin/gnutar -tf - | more Read error: I/O error 0+0 records in 0+0 records out gzip: stdin: unexpected end of file I had followed Gene's instructions and saved the label via DD and restored it to the tape as shown in an earlier email. This was the procedure to set the blksize in the tape and dd the label back. samar 24# mt -f /dev/sdlt2 blksize Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: Variable I am using /dev/sdlt2 link to /dev/rmt/tps1d4nrns - no rewind, non-byte swap device. I am no longer using the trailing 'v' device which would normally provide variable length blocks. I will demonstrate with the next tape SAMAR06 in slot 5. samar 27# mt -f /dev/sdlt2 rewind samar 28# dd if=/dev/sdlt2 of=./scratch Read error: Invalid argument 0+0 records in 0+0 records out Remembering that I'd setblksize yesterday prior to running amlabel -f samar 29# dd if=/dev/sdlt2 of=./scratch bs=32k 1+0 records in 1+0 records out samar 30# ls -las scratch 64 -rw-r--r--1 root sys32768 Jan 7 15:36 scratch AMANDA: TAPESTART DATE X TAPE SAMAR06$ ^L$ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ ** many nulls removed samar 32# mt -f /dev/sdlt2 blksize Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: 32768 byte(s) samar 33# mt -f /dev/sdlt2 rewind samar 34# mt -f /dev/sdlt2 blksize Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: 32768 byte(s) samar 35# dd bs=32768 if=scratch of=/dev/sdlt2 1+0 records in 1+0 records out That out of the way I'll go back and see what the other outstanding questions/tests where. --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773
Re: amrestore problem, headers ok but no data
On Fri, Jan 07, 2005 at 03:40:12PM -0500, Brian Cuttler wrote: samar 24# mt -f /dev/sdlt2 blksize Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: Variable I am using /dev/sdlt2 link to /dev/rmt/tps1d4nrns - no rewind, non-byte swap device. I am no longer using the trailing 'v' device which would normally provide variable length blocks. Brian, as you were using the 'v', might the data on the tapes have been written with some 32K block size? All of your dd's seem to fail after the header. How about trying a couple of mt fsf # to some file in the middle (on the no rewind device), then do dd's with bs=128k and/or bs=1024k and/or bs=16384k. jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: amrestore problem, headers ok but no data
On Friday 07 January 2005 15:40, Brian Cuttler wrote: samar 5# /usr/local/sbin/amrestore -r /dev/sdlt2 amrestore: 0: skipping start of tape: date 20050107 label SAMAR05 amrestore: 1: restoring samar._usr5_amanda.20050107.1 amrestore: read error: I/O error samar 6# mt -f /dev/sdlt2 rewind samar 7# mt -f /dev/sdlt2 fsf 1 samar 8# dd if=/dev/sdlt2 bs=32768 of=samar._usr5_amanda.20050107.1 skip=1 Read error: I/O error 1+0 records in 1+0 records out samar 9# mt -f /dev/sdlt2 rewind samar 10# mt -f /dev/sdlt2 fsf 1 samar 11# dd if=/dev/sdlt2 bs=32768 of=samar._usr5_amanda.20050107.1 Read error: I/O error 1+0 records in 1+0 records out samar 12# mt -f /dev/sdlt2 rewind samar 13# mt -f /dev/sdlt2 fsf 1 samar 14# cat -evt /dev/sdlt2 | more Input error: Invalid argument (/dev/sdlt2) samar 15# mt -f /dev/sdlt2 rewind samar 16# mt -f /dev/sdlt2 fsf 1 samar 17# dd if=/dev/sdlt2 bs=32768| cat -evt | more AMANDA: FILE 20050107 samar /usr5/amanda lev 1 comp .gz program /usr/local/sbin/ gnutar$ To restore, position tape at start of file and run:$ ^Idd if=tape bs=32k skip=1 | /usr/sbin/gzip -dc | usr/local/sbin/gnutar -f... -$ ^L$ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] @[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ ** many null characters removed. samar 18# mt -f /dev/sdlt2 rewind samar 19# mt -f /dev/sdlt2 fsf 1 samar 23# dd if=/dev/sdlt2 bs=32768 skip=1 | /usr/sbin/gzip -dc | /usr/local/sbin/gnutar -tf - | more Read error: I/O error 0+0 records in 0+0 records out gzip: stdin: unexpected end of file I had followed Gene's instructions and saved the label via DD and restored it to the tape as shown in an earlier email. This was the procedure to set the blksize in the tape and dd the label back. samar 24# mt -f /dev/sdlt2 blksize This is querying the tape only, and I guess the bigger tapes like bigger blocksizes by default. Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: Variable This I think, is not good. I am using /dev/sdlt2 link to /dev/rmt/tps1d4nrns - no rewind, non-byte swap device. I am no longer using the trailing 'v' device which would normally provide variable length blocks. I will demonstrate with the next tape SAMAR06 in slot 5. samar 27# mt -f /dev/sdlt2 rewind samar 28# dd if=/dev/sdlt2 of=./scratch Read error: Invalid argument 0+0 records in 0+0 records out Remembering that I'd setblksize yesterday prior to running amlabel -f samar 29# dd if=/dev/sdlt2 of=./scratch bs=32k 1+0 records in 1+0 records out samar 30# ls -las scratch 64 -rw-r--r--1 root sys32768 Jan 7 15:36 scratch Ok, what happens if you don't spec the blocksize, but just a count of 1 on a rewound tape. Then what size of scratch file do you get? AMANDA: TAPESTART DATE X TAPE SAMAR06$ ^L$ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] @[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ ** many nulls removed samar 32# mt -f /dev/sdlt2 blksize Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: 32768 byte(s) Aha, this one should be ok. samar 33# mt -f /dev/sdlt2 rewind samar 34# mt -f /dev/sdlt2 blksize Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: 32768 byte(s) samar 35# dd bs=32768 if=scratch of=/dev/sdlt2 1+0 records in 1+0 records out Which should have obtained the tapes label block, probably with about 32700 bytes of nulls appended. That out of the way I'll go back and see what the other outstanding questions/tests
Re: amrestore problem, headers ok but no data
On Fri, Jan 07, 2005 at 03:40:12PM -0500, Brian Cuttler wrote: samar 5# /usr/local/sbin/amrestore -r /dev/sdlt2 amrestore: 0: skipping start of tape: date 20050107 label SAMAR05 amrestore: 1: restoring samar._usr5_amanda.20050107.1 amrestore: read error: I/O error [likewise with dd bs=32k] Ooo, I don't like the look of I/O error at all. That suggests a hardware or media problem, as opposed to anything that software has any control over. If you haven't done so (can't recall; maybe you've already described this), look in the system logs for errors from that device. If there aren't any, it couldn't hurt to take a look at the driver's man page (and pages for the SCSI subsystem in general -- it is a SCSI drive, isn't it?) to see if more verbose error reporting can be enabled. If you come up with anything, please post it. samar 12# mt -f /dev/sdlt2 rewind samar 13# mt -f /dev/sdlt2 fsf 1 samar 14# cat -evt /dev/sdlt2 | more Input error: Invalid argument (/dev/sdlt2) This one's to be expected. cat uses a smaller block size -- and unlike dd, you can't change it. samar 15# mt -f /dev/sdlt2 rewind samar 16# mt -f /dev/sdlt2 fsf 1 samar 17# dd if=/dev/sdlt2 bs=32768| cat -evt | more AMANDA: FILE 20050107 samar /usr5/amanda lev 1 comp .gz program /usr/local/sbin/ gnutar$ To restore, position tape at start of file and run:$ ^Idd if=tape bs=32k skip=1 | /usr/sbin/gzip -dc | usr/local/sbin/gnutar -f... -$ ^L$ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ ** many null characters removed. Hmmm, I'd have expected to see Read error: I/O error again here, seeing as you get it on every other 32-KB read. Odd that the message is missing while the main output is still as though the error had occurred. samar 18# mt -f /dev/sdlt2 rewind samar 19# mt -f /dev/sdlt2 fsf 1 samar 23# dd if=/dev/sdlt2 bs=32768 skip=1 | /usr/sbin/gzip -dc | /usr/local/sbin/gnutar -tf - | more Read error: I/O error 0+0 records in 0+0 records out gzip: stdin: unexpected end of file Yeah, more of same... If dd can't get the bits off the tape, there's not much point trying to do different things with its nonexistent output :-( I had followed Gene's instructions I've never had to use these, so my comments here are pretty tentative. [Commands to show that the tape drive is set for variable-length blocks, stash the label in ./scratch, and verify that the label was stashed ok.] I don't see the command to set the drive to 32768-byte blocks, but it's presumably there becuse: samar 32# mt -f /dev/sdlt2 blksize Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: 32768 byte(s) samar 33# mt -f /dev/sdlt2 rewind samar 34# mt -f /dev/sdlt2 blksize Recommended tape I/O size: 131072 bytes (256 512-byte blocks) Minimum block size: 4 byte(s) Maximum block size: 16777212 bytes Current block size: 32768 byte(s) samar 35# dd bs=32768 if=scratch of=/dev/sdlt2 1+0 records in 1+0 records out If I recall from Gene's description of the problem, it's only when you go to *read* a tape that your setting gets magically zapped. So it couldn't hurt to do a final: mt rewind dd bs=32k /dev/sdlt2 ./scratch2 mt -f /dev/sdlt2 blksize to verify that that hasn't happened. -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The animal that coils in a circle is the serpent; that's why so many cults and myths of the serpent exist, because it's hard to represent the return of the sun by the coiling of a hippopotamus. - Umberto Eco, Foucault's Pendulum
Re: amrestore problem, headers ok but no data
Gene, Thanks for the tape label sequence, will re-label the next couple of tapes and see if I don't get different results from the next amdump run. (commands reproduced below). If this solves the problem perhaps it should be incorporated into amlabel. Alexander, Hadn't realized that the 1st chunk on disk was broken into the amanda header followed by the collected chuncks. Makes sense if you think about it. New information-- The amdump run I started yesterday completed in record time. 51 hours of dump time and only 33 hours of elapse time. I tried to amrestore several dumps from the tape to disk, oddly the restores of the DUMP DLE both failed, the restore of the TAR DLE sort of worked, I can... I'm an idiot. I was able to take the DLE restored from tape and # tar -tf the tar ball but was unable to restore it with # tar -xvf. On second look I've realized that I can, and MUST, use gnutar and was then able to restore the files. Suddenly its looking like TAR DLEs are a non-issue. (well, move below) Things are still anomalous with the DUMP DLEs though. samar 22# mt -f /dev/sdlt2 rewind samar 23# /usr/local/sbin/amrestore /dev/sdlt2 samar /usr1 amrestore: 0: skipping start of tape: date 20041229 label SAMAR24 amrestore: 1: skipping samar._usr5_lalor.20041229.0 amrestore: 2: skipping samar._usr5_tapu.20041229.1 amrestore: 3: skipping samar._.20041229.1 amrestore: 4: skipping samar._usr5_amanda.20041229.1 amrestore: 5: skipping samar._usr5_bimal.20041229.1 amrestore: 6: skipping samar._usr5_allengr.20041229.2 amrestore: 7: skipping samar._usr5_skaur.20041229.1 amrestore: 8: skipping samar._usr5_leith.20041229.1 amrestore: 9: skipping samar._usr5_hxgao.20041229.1 amrestore: 10: skipping samar._usr5_ninggao.20041229.1 amrestore: 11: restoring samar._usr1.20041229.0 amrestore: read error: I/O error gzip: stdin: unexpected end of file This created a zero length file for samar._usr1.20041229.0 Same result for the DUMP DLE for the root partition. Same result when I tried to pipe directly to xfsrestore. samar 31# /usr/local/sbin/amrestore -p /dev/sdlt2 samar /usr5/bimal | /usr/local/sbin/gnutar -tf - amrestore: 0: skipping start of tape: date 20041229 label SAMAR24 amrestore: 1: skipping samar._usr5_lalor.20041229.0 amrestore: 2: skipping samar._usr5_tapu.20041229.1 amrestore: 3: skipping samar._.20041229.1 amrestore: 4: skipping samar._usr5_amanda.20041229.1 amrestore: 5: restoring samar._usr5_bimal.20041229.1 ./ ./cvs_test/ ./cvs_test/spider/ ./cvs_test/spider/CVS/ ./cvs_test/spider/man/ amrestore./cvs_test/spider/man/CVS/ : read error: I/O error./cvs_test/spider/src/ ./cvs_test/spider/src/CVS/ ./hpc/ ./hpc/eve/ ./hpc/eve/hpc/ ./hpc/eve/hpc/dynamic/ ./hpc/eve/hpc/dynamic/new/ --lines removed for brevity (like that'll help now). ./pick_part/classify/Power_Spectra/power/ ./pick_part/classify/Reconstruction/ ./pick_part/classify/Refinement/ ./pick_part/final/ ./pick_part/final/0deg_proj_asym_mask/ ./pick_part/final/0deg_proj_asym_mask/interpolated/ ./pick_part/final/0deg_proj_asym_mask/interpolated/new/ ./pick_part/final/0deg_proj_sym_mask/ gzip: stdin: unexpected end of file ./pick_part/final/0deg_proj_sym_mask/interpolated/ /usr/local/sbin/gnutar: Unexpected EOF in archive /usr/local/sbin/gnutar: Error is not recoverable: exiting now Actually at this point I'm not sure... that file name is familiar and I don't know we didn't error while writing the file to tape in the first place. No errors reported in the amdump report, read of disk was completely clean, unlike the previous output that I posted. We are close, but the results of this run seem to weaken the argument for disk block/record issues. I can switch to a fixed length device by removing the trailing 'v' in the device name. It hasn't been an issue on other systems though I admit that this SDLT on IRIX is unique at my site. Those are commands in the 'mt' arsenal Brian. And there have been known to be platform diffs, so consult the manpages for your version, and, make sure you have the latest version. Mine possibly isn't quite fresh and 100% green, but it works and returns: mt-st v. 0.7 for an mt --version command Back when I was running real tapes, I found that a 32kilobyte record was measureable faster than the default of 512 bytes. But, if everything isn't set to the same record length, the whole thing blew up for me. Is there any way you can make it run fixed length records on that lashup? Block size on tape. Where is that set, is this a function of the underlying DD command within Amanda or is this elsewhere ? You can spec the block size used by dd with the bs option, but the tape itself must know about it first by useing the appropriate mt command. Again, there are platform diffs, but here is the -h output from my copy: [EMAIL PROTECTED] root]# mt -h usage: mt [-v] [--version] [-h] [ -f device ] command [ count ] commands: weof, wset,
Re: amrestore problem, headers ok but no data
On Friday 31 December 2004 10:49, Brian Cuttler wrote: Gene, Thanks for the tape label sequence, will re-label the next couple of tapes and see if I don't get different results from the next amdump run. (commands reproduced below). If this solves the problem perhaps it should be incorporated into amlabel. Alexander, Hadn't realized that the 1st chunk on disk was broken into the amanda header followed by the collected chuncks. Makes sense if you think about it. New information-- The amdump run I started yesterday completed in record time. 51 hours of dump time and only 33 hours of elapse time. I tried to amrestore several dumps from the tape to disk, oddly the restores of the DUMP DLE both failed, the restore of the TAR DLE sort of worked, I can... I'm an idiot. I was able to take the DLE restored from tape and # tar -tf the tar ball but was unable to restore it with # tar -xvf. On second look I've realized that I can, and MUST, use gnutar and was then able to restore the files. Suddenly its looking like TAR DLEs are a non-issue. (well, move below) Things are still anomalous with the DUMP DLEs though. samar 22# mt -f /dev/sdlt2 rewind samar 23# /usr/local/sbin/amrestore /dev/sdlt2 samar /usr1 amrestore: 0: skipping start of tape: date 20041229 label SAMAR24 amrestore: 1: skipping samar._usr5_lalor.20041229.0 amrestore: 2: skipping samar._usr5_tapu.20041229.1 amrestore: 3: skipping samar._.20041229.1 amrestore: 4: skipping samar._usr5_amanda.20041229.1 amrestore: 5: skipping samar._usr5_bimal.20041229.1 amrestore: 6: skipping samar._usr5_allengr.20041229.2 amrestore: 7: skipping samar._usr5_skaur.20041229.1 amrestore: 8: skipping samar._usr5_leith.20041229.1 amrestore: 9: skipping samar._usr5_hxgao.20041229.1 amrestore: 10: skipping samar._usr5_ninggao.20041229.1 amrestore: 11: restoring samar._usr1.20041229.0 amrestore: read error: I/O error gzip: stdin: unexpected end of file This created a zero length file for samar._usr1.20041229.0 Same result for the DUMP DLE for the root partition. Same result when I tried to pipe directly to xfsrestore. samar 31# /usr/local/sbin/amrestore -p /dev/sdlt2 samar /usr5/bimal | /usr/local/sbin/gnutar -tf - amrestore: 0: skipping start of tape: date 20041229 label SAMAR24 amrestore: 1: skipping samar._usr5_lalor.20041229.0 amrestore: 2: skipping samar._usr5_tapu.20041229.1 amrestore: 3: skipping samar._.20041229.1 amrestore: 4: skipping samar._usr5_amanda.20041229.1 amrestore: 5: restoring samar._usr5_bimal.20041229.1 ./ ./cvs_test/ ./cvs_test/spider/ ./cvs_test/spider/CVS/ ./cvs_test/spider/man/ amrestore./cvs_test/spider/man/CVS/ : read error: I/O error./cvs_test/spider/src/ ./cvs_test/spider/src/CVS/ ./hpc/ ./hpc/eve/ ./hpc/eve/hpc/ ./hpc/eve/hpc/dynamic/ ./hpc/eve/hpc/dynamic/new/ --lines removed for brevity (like that'll help now). ./pick_part/classify/Power_Spectra/power/ ./pick_part/classify/Reconstruction/ ./pick_part/classify/Refinement/ ./pick_part/final/ ./pick_part/final/0deg_proj_asym_mask/ ./pick_part/final/0deg_proj_asym_mask/interpolated/ ./pick_part/final/0deg_proj_asym_mask/interpolated/new/ ./pick_part/final/0deg_proj_sym_mask/ gzip: stdin: unexpected end of file ./pick_part/final/0deg_proj_sym_mask/interpolated/ /usr/local/sbin/gnutar: Unexpected EOF in archive /usr/local/sbin/gnutar: Error is not recoverable: exiting now Actually at this point I'm not sure... that file name is familiar and I don't know we didn't error while writing the file to tape in the first place. No errors reported in the amdump report, read of disk was completely clean, unlike the previous output that I posted. We are close, but the results of this run seem to weaken the argument for disk block/record issues. But, otoh, its strengthening the argument to use gnutar only. And I'd make the suggestion that somewhere in this setup, there is insufficient iron to do the job. I don't know anything about an SDLT, but if its taking 33 hours of real time, that drive has got to be doing a lot of shoe shining where it collects data till the buffer is about full, starts up and dumps that to the tape, then stops and does a short rewind so that it doesn't waste a lot of blank tape in between data writes. The server should have enough bandwidth at the drive cable to keep the pipe full so that once it starts, it streams data at the rate the drive can take it, at least for the duration of that dle's dump from the holding disk. A 150 mhz cyrix hasn't the power, and here, a 400mhz k6-II wasn't able to keep a puny little DDS2 drive 100% busy either. Here, using virtual tapes on a dedicated hard drive, a 16GB before compression backup run that fits in a bit over 9GB after gzip gets through with it, starts a few minutes after midnight, and is often done by 2:15 am. But, during the dump time from the holding disk to the virtual tape, the machine is virtually frozen, only the xwindow clock seems to keep on counting
Re: amrestore problem, headers ok but no data
Hi, on Wednesday 29 December 2004 16:29, Brian Cuttler wrote: Amanda2.4.4p1-20030716 SGI/IRIX 6.5.19m mtx 1.3.8 8 Slot jukebox with SDLT 320 (Quantum) gnutar1.13.25 I suppose this configuration looks familiar to some of you. I was in the process of writing an email to thank Stefan Weichinger, Gene Heskett and Eric Siegerman for the terrific and patient help they gave me with my new amanda config. Welcome ;-) I am able to see the DLEs on tape but I'm unable to retried any data, either from the dump or the tar partitions. samar 144# mt -f /dev/sdlt2 rewind samar 145# /usr/local/sbin/amrestore /dev/sdlt2 samar /usr5/dtaylor amrestore: 0: skipping start of tape: date 20041227 label SAMAR23 amrestore: 1: skipping samar._usr1.20041227.1 amrestore: 2: skipping samar._usr5_lalor.20041227.1 amrestore: 3: skipping samar._usr5_amanda.20041227.0 amrestore: 4: restoring samar._usr5_dtaylor.20041227.1 amrestore: read error: I/O error gzip: stdin: unexpected end of file And you don't get a file with this command? I once had this behavior on one of my machines, just have to remember ... You could also try to specify the blocksize with the amrestore-option -b, maybe this is not detected correctly. Do you use DUMP or TAR for samar._usr5_dtaylor? I am able to use amrestore with the -r option which results in files like this samar 77# more samar._usr5_lalor.20041227.1 AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program /usr/local/sbin/gnutar To restore, position tape at start of file and run: dd if=tape bs=32k skip=1 | /usr/sbin/gzip -dc | usr/local/sbin/gnutar -f... - where the rest of the file is empty. Tried this with one of my holdingdisk-chunks, the rest is not empty here. I should be more explicite. samar 82# ls -las samar._usr5_lalor.20041227.1 64 -rw-r- 1 root sys 32768 Dec 29 15:36 samar._usr5_lalor.20041227.1 This one is only 32768 kB in size ... a header. samar 79# cat -evt samar._usr5_lalor.20041227.1 | head AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program /usr/local/sbin/g nutar$ To restore, position tape at start of file and run:$ ^Idd if=tape bs=32k skip=1 | /usr/sbin/gzip -dc | usr/local/sbin/gnutar -f... -$ ^L$ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] @[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] @[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] @[EMAIL PROTECTED]@ The file headers are there, I just don't know where the data has gotten to. I certainly see multiple chunksize files in the work area when I'm running amdump. Are the chunks still there? This would explain why the headers have made it to the tape, while the data (or parts of it) is still in the holdingdisk. (This is also a lev1-dump, so the question is, if there were any changes at all?) What did the REPORT-mail say? I've otherwise tested the tape drive with the native version of # tar and have been able to write and recover data. Besides the amrestore listing is out there. # mt commands seem to run progressively longer as I read the tape, I'm apparently writing lots of something between EOF marks, I'm just hoping that its actual data. # ls -las /dev/sdlt2 lrwxr-xr-x1 root sys 20 Nov 22 14:45 /dev/sdlt2 - /dev/rmt/tps1d4nrnsv ie, bus 1, target (SCSI id) 4, non-rewinding, non-bytes-wapping, variable length records. Similar to what I run on other systems. Seems ok so far, let's debug the upper points first. -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: amrestore problem, headers ok but no data
Gene, Stefan, * I'm gonna remove a lot of text from the middle of this. On Wednesday 29 December 2004 16:29, Brian Cuttler wrote: ## Amanda2.4.4p1-20030716 ## SGI/IRIX 6.5.19m ## mtx 1.3.8 ## 8 Slot jukebox with SDLT 320 (Quantum) ## gnutar1.13.25 ## ## I'm planning to dump 2-3 times per week but have been starting the ## process manually (via the # at command) and have seen dumps in only ## 50 hours, down from hundreds when I initially started the server up. ## ## By all accounts everything is working properly, some tuning is still ## in order but there are no apparent errors. Or where not until I ## tried to test the file restore process. ## ## I am able to see the DLEs on tape but I'm unable to retried any ## data, either from the dump or the tar partitions. ## ## samar 144# mt -f /dev/sdlt2 rewind ## samar 145# /usr/local/sbin/amrestore /dev/sdlt2 samar /usr5/dtaylor ## amrestore: 0: skipping start of tape: date 20041227 label SAMAR23 ## amrestore: 1: skipping samar._usr1.20041227.1 ## amrestore: 2: skipping samar._usr5_lalor.20041227.1 ## amrestore: 3: skipping samar._usr5_amanda.20041227.0 ## amrestore: 4: restoring samar._usr5_dtaylor.20041227.1 ## amrestore: read error: I/O error ## ## gzip: stdin: unexpected end of file ## ## ## I am able to use amrestore with the -r option which results in ## files like this ## ## ## samar 77# more samar._usr5_lalor.20041227.1 ## AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program ## /usr/local/sbin/gnutar To restore, position tape at start of file ## and run: ## dd if=tape## bs=32k skip=1 | /usr/sbin/gzip -dc | ## usr/local/sbin/gnutar -f... - ## ## ## where the rest of the file is empty. I should be more explicite. ## ## samar 82# ls -las samar._usr5_lalor.20041227.1 ## 64 -rw-r- 1 root sys 32768 Dec 29 15:36 ## samar._usr5_lalor.20041227.1 ## ## samar 79# cat -evt samar._usr5_lalor.20041227.1 | head ## AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program ## /usr/local/sbin/g nutar$ ## To restore, position tape at start of file and run:$ ## ^Idd if=tape## bs=32k skip=1 | /usr/sbin/gzip -dc | ## usr/local/sbin/gnutar -f... -$ ## ^L$ ## [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ ## [EMAIL PROTECTED]@ ## [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] ## @[EMAIL PROTECTED]@ ## [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] ## @[EMAIL PROTECTED]@ ## [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] ## @[EMAIL PROTECTED]@ ## ## The file headers are there, I just don't know where the data has ## gotten to. I certainly see multiple chunksize files in the work ## area when I'm running amdump. ## ## I've otherwise tested the tape drive with the native version of # ## tar and have been able to write and recover data. Besides the ## amrestore listing is out there. ## ## # mt commands seem to run progressively longer as I read the tape, ## I'm apparently writing lots of something between EOF marks, I'm ## just hoping that its actual data. ## ## # ls -las /dev/sdlt2 ## lrwxr-xr-x1 root sys 20 Nov 22 14:45 /dev/sdlt2 -## ## /dev/rmt/tps1d4nrnsv The two things I'd question are: what version of tar? We've found that tar-1.13-19 and 1.13-25. We've had a report of 1.14 not working a week or 2 back up the log. And earlier versions than 1.13-19 were mistakenly putting a number of some kind at the start of the header, which wasn't compatible with manda. Confirm, I am using GNU tar 1.13.25 samar 35# /usr/local/sbin/gnutar --version tar (GNU tar) 1.13.25 And I'd observe that amanda generally uses a fixed length record. I can switch to a fixed length device by removing the trailing 'v' in the device name. It hasn't been an issue on other systems though I admit that this SDLT on IRIX is unique at my site. Back when I was running real tapes, I found that a 32kilobyte record was
Re: amrestore problem, headers ok but no data
On Thursday 30 December 2004 14:55, Brian Cuttler wrote: Gene, Stefan, * I'm gonna remove a lot of text from the middle of this. On Wednesday 29 December 2004 16:29, Brian Cuttler wrote: ## Amanda2.4.4p1-20030716 ## SGI/IRIX 6.5.19m ## mtx 1.3.8 ## 8 Slot jukebox with SDLT 320 (Quantum) ## gnutar1.13.25 ## ## I'm planning to dump 2-3 times per week but have been starting the ## process manually (via the # at command) and have seen dumps in only ## 50 hours, down from hundreds when I initially started the server up. ## ## By all accounts everything is working properly, some tuning is still ## in order but there are no apparent errors. Or where not until I ## tried to test the file restore process. ## ## I am able to see the DLEs on tape but I'm unable to retried any ## data, either from the dump or the tar partitions. ## ## samar 144# mt -f /dev/sdlt2 rewind ## samar 145# /usr/local/sbin/amrestore /dev/sdlt2 samar /usr5/dtaylor ## amrestore: 0: skipping start of tape: date 20041227 label SAMAR23 ## amrestore: 1: skipping samar._usr1.20041227.1 ## amrestore: 2: skipping samar._usr5_lalor.20041227.1 ## amrestore: 3: skipping samar._usr5_amanda.20041227.0 ## amrestore: 4: restoring samar._usr5_dtaylor.20041227.1 ## amrestore: read error: I/O error ## ## gzip: stdin: unexpected end of file ## ## ## I am able to use amrestore with the -r option which results in ## files like this ## ## ## samar 77# more samar._usr5_lalor.20041227.1 ## AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program ## /usr/local/sbin/gnutar To restore, position tape at start of file ## and run: ## dd if=tape## bs=32k skip=1 | /usr/sbin/gzip -dc | ## usr/local/sbin/gnutar -f... - ## ## ## where the rest of the file is empty. I should be more explicite. ## ## samar 82# ls -las samar._usr5_lalor.20041227.1 ## 64 -rw-r- 1 root sys 32768 Dec 29 15:36 ## samar._usr5_lalor.20041227.1 ## ## samar 79# cat -evt samar._usr5_lalor.20041227.1 | head ## AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program ## /usr/local/sbin/g nutar$ ## To restore, position tape at start of file and run:$ ## ^Idd if=tape## bs=32k skip=1 | /usr/sbin/gzip -dc | ## usr/local/sbin/gnutar -f... -$ ## ^L$ ## [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] @ ## [EMAIL PROTECTED]@ ## [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] ## @[EMAIL PROTECTED]@ ## [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] ## @[EMAIL PROTECTED]@ ## [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] ## @[EMAIL PROTECTED]@ ## ## The file headers are there, I just don't know where the data has ## gotten to. I certainly see multiple chunksize files in the work ## area when I'm running amdump. ## ## I've otherwise tested the tape drive with the native version of # ## tar and have been able to write and recover data. Besides the ## amrestore listing is out there. ## ## # mt commands seem to run progressively longer as I read the tape, ## I'm apparently writing lots of something between EOF marks, I'm ## just hoping that its actual data. ## ## # ls -las /dev/sdlt2 ## lrwxr-xr-x1 root sys 20 Nov 22 14:45 /dev/sdlt2 -## ## /dev/rmt/tps1d4nrnsv The two things I'd question are: what version of tar? We've found that tar-1.13-19 and 1.13-25. We've had a report of 1.14 not working a week or 2 back up the log. And earlier versions than 1.13-19 were mistakenly putting a number of some kind at the start of the header, which wasn't compatible with manda. Confirm, I am using GNU tar 1.13.25 Good version samar 35# /usr/local/sbin/gnutar --version tar (GNU tar) 1.13.25 And I'd observe that amanda generally uses a fixed length record. I can switch to a fixed length device by removing the trailing 'v' in the device name. It hasn't been an issue on other systems though I admit that this SDLT on IRIX is unique at my site.
amrestore problem, headers ok but no data
Amanda2.4.4p1-20030716 SGI/IRIX 6.5.19m mtx 1.3.8 8 Slot jukebox with SDLT 320 (Quantum) gnutar1.13.25 I suppose this configuration looks familiar to some of you. I was in the process of writing an email to thank Stefan Weichinger, Gene Heskett and Eric Siegerman for the terrific and patient help they gave me with my new amanda config. I don't wish to diminish the thanks but must sadly ask for further help. Unfortuanately I have yet another issue... but we'll get to that later. Currently we are using the jukebox, have DLE types of both xfsdump for the root and /usr1 partitions and of type TAR (gnutar) for DLEs that match the (top of partition) user directories on the Raid Array (.86 Tbytes). I've assigned a directory on the raid array to act as the work area (but was careful to not list it as a DLE) and have increased the maxdump to something larger than 1. We are still client contrained but 3 concurrent dumps is an aweful lot better than one. [I should also say that this system is the sole client of the server resident on this system]. I have also set the dump cycle to 2 weeks rather than one. I'm planning to dump 2-3 times per week but have been starting the process manually (via the # at command) and have seen dumps in only 50 hours, down from hundreds when I initially started the server up. By all accounts everything is working properly, some tuning is still in order but there are no apparent errors. Or where not until I tried to test the file restore process. I am able to see the DLEs on tape but I'm unable to retried any data, either from the dump or the tar partitions. samar 144# mt -f /dev/sdlt2 rewind samar 145# /usr/local/sbin/amrestore /dev/sdlt2 samar /usr5/dtaylor amrestore: 0: skipping start of tape: date 20041227 label SAMAR23 amrestore: 1: skipping samar._usr1.20041227.1 amrestore: 2: skipping samar._usr5_lalor.20041227.1 amrestore: 3: skipping samar._usr5_amanda.20041227.0 amrestore: 4: restoring samar._usr5_dtaylor.20041227.1 amrestore: read error: I/O error gzip: stdin: unexpected end of file I am able to use amrestore with the -r option which results in files like this samar 77# more samar._usr5_lalor.20041227.1 AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program /usr/local/sbin/gnutar To restore, position tape at start of file and run: dd if=tape bs=32k skip=1 | /usr/sbin/gzip -dc | usr/local/sbin/gnutar -f... - where the rest of the file is empty. I should be more explicite. samar 82# ls -las samar._usr5_lalor.20041227.1 64 -rw-r- 1 root sys 32768 Dec 29 15:36 samar._usr5_lalor.20041227.1 samar 79# cat -evt samar._usr5_lalor.20041227.1 | head AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program /usr/local/sbin/g nutar$ To restore, position tape at start of file and run:$ ^Idd if=tape bs=32k skip=1 | /usr/sbin/gzip -dc | usr/local/sbin/gnutar -f... -$ ^L$ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ The file headers are there, I just don't know where the data has gotten to. I certainly see multiple chunksize files in the work area when I'm running amdump. I've otherwise tested the tape drive with the native version of # tar and have been able to write and recover data. Besides the amrestore listing is out there. # mt commands seem to run progressively longer as I read the tape, I'm apparently writing lots of something between EOF marks, I'm just hoping that its actual data. # ls -las /dev/sdlt2 lrwxr-xr-x1 root sys 20 Nov 22 14:45 /dev/sdlt2 - /dev/rmt/tps1d4nrnsv ie, bus 1, target (SCSI id) 4, non-rewinding, non-bytes-wapping, variable length records. Similar to what I run on other systems. Thank you all for your help, past,
Re: amrestore problem, headers ok but no data
On Wednesday 29 December 2004 16:29, Brian Cuttler wrote: Amanda2.4.4p1-20030716 SGI/IRIX 6.5.19m mtx 1.3.8 8 Slot jukebox with SDLT 320 (Quantum) gnutar1.13.25 I suppose this configuration looks familiar to some of you. I was in the process of writing an email to thank Stefan Weichinger, Gene Heskett and Eric Siegerman for the terrific and patient help they gave me with my new amanda config. I don't wish to diminish the thanks but must sadly ask for further help. Unfortuanately I have yet another issue... but we'll get to that later. Currently we are using the jukebox, have DLE types of both xfsdump for the root and /usr1 partitions and of type TAR (gnutar) for DLEs that match the (top of partition) user directories on the Raid Array (.86 Tbytes). I've assigned a directory on the raid array to act as the work area (but was careful to not list it as a DLE) and have increased the maxdump to something larger than 1. We are still client contrained but 3 concurrent dumps is an aweful lot better than one. [I should also say that this system is the sole client of the server resident on this system]. I have also set the dump cycle to 2 weeks rather than one. I'm planning to dump 2-3 times per week but have been starting the process manually (via the # at command) and have seen dumps in only 50 hours, down from hundreds when I initially started the server up. By all accounts everything is working properly, some tuning is still in order but there are no apparent errors. Or where not until I tried to test the file restore process. I am able to see the DLEs on tape but I'm unable to retried any data, either from the dump or the tar partitions. samar 144# mt -f /dev/sdlt2 rewind samar 145# /usr/local/sbin/amrestore /dev/sdlt2 samar /usr5/dtaylor amrestore: 0: skipping start of tape: date 20041227 label SAMAR23 amrestore: 1: skipping samar._usr1.20041227.1 amrestore: 2: skipping samar._usr5_lalor.20041227.1 amrestore: 3: skipping samar._usr5_amanda.20041227.0 amrestore: 4: restoring samar._usr5_dtaylor.20041227.1 amrestore: read error: I/O error gzip: stdin: unexpected end of file I am able to use amrestore with the -r option which results in files like this samar 77# more samar._usr5_lalor.20041227.1 AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program /usr/local/sbin/gnutar To restore, position tape at start of file and run: dd if=tape bs=32k skip=1 | /usr/sbin/gzip -dc | usr/local/sbin/gnutar -f... - where the rest of the file is empty. I should be more explicite. samar 82# ls -las samar._usr5_lalor.20041227.1 64 -rw-r- 1 root sys 32768 Dec 29 15:36 samar._usr5_lalor.20041227.1 samar 79# cat -evt samar._usr5_lalor.20041227.1 | head AMANDA: FILE 20041227 samar /usr5/lalor lev 1 comp .gz program /usr/local/sbin/g nutar$ To restore, position tape at start of file and run:$ ^Idd if=tape bs=32k skip=1 | /usr/sbin/gzip -dc | usr/local/sbin/gnutar -f... -$ ^L$ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] @[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] @[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] @[EMAIL PROTECTED]@ The file headers are there, I just don't know where the data has gotten to. I certainly see multiple chunksize files in the work area when I'm running amdump. I've otherwise tested the tape drive with the native version of # tar and have been able to write and recover data. Besides the amrestore listing is out there. # mt commands seem to run progressively longer as I read the tape, I'm apparently writing lots of something between EOF marks, I'm just hoping that its actual data. # ls -las /dev/sdlt2 lrwxr-xr-x1 root sys 20 Nov 22 14:45 /dev/sdlt2 - /dev/rmt/tps1d4nrnsv ie, bus 1, target (SCSI id) 4, non-rewinding, non-bytes-wapping, variable length
