Re: amanda 2.6.1 amrestore issue
On Mon, Feb 23, 2009 at 3:18 PM, Brian Cuttler wrote: > amdevchec liked the drive, and amlabel and amcheck report > success when labeling or checking it. Sorry, I didn't mean to reply privately in my last message. Anyway, can you try running the amrestore under 'truss' to see what is going on at the syscall level? Just snip the part between where it opens the tape device and the final error message. Dustin -- Storage Software Engineer http://www.zmanda.com
Re: amanda 2.6.1 amrestore issue
Are you able to manually seek to this tape file on this same host and device? mt -f /dev/rmt/0hn asf 2 If so, can you read the header? dd if=/dev/rmt/0hn bs=32k count=1 Trying to narrow it down to the device/tape or Amanda. Paul On Mon, 2009-02-23 at 14:40 -0500, Brian Cuttler wrote: > I'm running amanda 2.6.1 on Solaris 10/x86 and having a problem with > my test of a file restore. > > tapedev is /dev/rmt/0hn, its an LTO4, should probably just use /dev/rmt/0n. > Tape is imbedded in an SL24 jukebox, the the problem doesn't seem related > to the robot. > > Interestingly, same version was able to run a restore on DLT drive > on solaris 10/Sparc, so I'm thinking me rather than architecture > (that is solaris sparc v x86, not Amanda architecture), but I don't > know for sure. > > Target file system is ZFS produced with snapshots, but again, parallel > config with the Sparc system. > > # amrestore /dev/rmt/0hn > Restoring from tape Curie01 starting with file 1. > amrestore: 1: restoring FILE: date 20090223143428 host curie disk /thump lev > 1 comp .gz program APPLICATION > Could not seek device /dev/rmt/0hn to file 2: Error reading Amanda header. > > > --- >Brian R Cuttler brian.cutt...@wadsworth.org >Computer Systems Support(v) 518 486-1697 >Wadsworth Center(f) 518 473-6384 >NYS Department of HealthHelp Desk 518 473-0773 > > > > IMPORTANT NOTICE: This e-mail and any attachments may contain > confidential or sensitive information which is, or may be, legally > privileged or otherwise protected by law from further disclosure. It > is intended only for the addressee. If you received this in error or > from someone who was not authorized to send it to you, please do not > distribute, copy or use it or any attachments. Please notify the > sender immediately by reply e-mail and delete this from your > system. Thank you for your cooperation. > > -- Design Engineer Zmanda, Inc. http://www.zmanda.com/
Re: amanda 2.6.1 amrestore issue
I'm sorry -- I somehow filed this away withot answering.
On Mon, Feb 23, 2009 at 3:59 PM, Brian Cuttler wrote:
> read(4, 0x080887A0, 32768) Err#5 EIO
This is the read error. As you can see, it doesn't give much detail
-- just EIO. The subsequent
> ioctl(4, (('m'<<8)|1), 0x080469CC) = 0
is a rewind request, which is successful. I don't kow much about the
Solaris tape driver in general. 'man st' says:
EIO During opening, the tape device is not ready
because either no tape is in the drive, or the
drive is not on-line. Once open, this error is
returned if the requested I/O transfer could not
be completed.
Is there any indication of what this problem might be in the kernel logs?
Note that the actions Amanda is performing are:
open
rewind
read 32k blocks until getting an EOF indication:
/2: read(4, 0x08170A40, 32768) = 0
attempt to read the next block (which should begin the next file)
These steps aren't particularly easy to duplicate from the command
line, since 'dd' closes its input once it reaches an EOF.
Dustin
--
Storage Software Engineer
http://www.zmanda.com
Re: amanda 2.6.1 amrestore issue
On Fri, Feb 27, 2009 at 12:03:21PM -0500, Dustin J. Mitchell wrote: > I'm sorry -- I somehow filed this away withot answering. > > On Mon, Feb 23, 2009 at 3:59 PM, Brian Cuttler wrote: > > read(4, 0x080887A0, 32768) ? ? ? ? ? ? ? ? ? ? ?Err#5 EIO > ... > Note that the actions Amanda is performing are: > open > rewind > read 32k blocks until getting an EOF indication: >/2: read(4, 0x08170A40, 32768) = 0 > attempt to read the next block (which should begin the next file) > > These steps aren't particularly easy to duplicate from the command > line, since 'dd' closes its input once it reaches an EOF. You can use a shell workaround/trick to deal with this: # ( cmd1 cmd2 ... cmdn ) > /dev/"tapedevice" < /dev/"tapedevice" The shell creates a subprocess that runs the commands between the parentheses. Stdin and stdout are open to the tape device at the start of this subprocess and stays open through all cmds between the parens. Any dd commands between the parens should omit and "if=" and "of=" arguments as you want the defaults of stdin/out. jl -- Jon H. LaBadie j...@jgcomp.com JG Computing 12027 Creekbend Drive (703) 787-0884 Reston, VA 20194 (703) 787-0922 (fax)
