On Sun, Mar 14, 2010 at 01:42:38PM +0100, Filip Van Raemdonck wrote: > Hello, > > I've been trying to get amanda using a DDS4 tapedrive on OpenSolaris > 2009.06, and if I had more of it, I'd be pulling my hair out. > > Brief summary: from what I can tell, amtapetype loses the "block_size" > property on the device during/after it's first complete medium fill. > And probably more info about, or the whole device "pointer", causing > it to fail. > > Long story below: > > I built 2.6.1p2 -- using SUNWgcc -- without problems. > Before pointing to SUNWgcc as the culprit, please note that I also > installed a 2.6.1p1 package from OpenSolaris Source Juicer > (http://jucr.opensolaris.org/home/) which was build using Sun Studio > Express (cfr. http://jucr.opensolaris.org/build/viewlog/4129/), but > exhibits the same problem. > > When I try running amtapetype on a DDS3 medium, it does a compression > test, then writes 1 file to fill the whole tape, and when it's > finished doing that, it bails out with a message: > Wrote less than 100MB to the device: Error writing block: Error 0 > > I can tell it wrote out the whole tape because I ran amtapetype inside > script(1) and it has written about 375000 blocks, which at 32k default > amtapetype block is roughly 12GB or the size of a DDS3. > I tried a few other DDS3 media, with the same results; DDS2 media too > behave the same. > I'm running amtapetype on an actual DDS4 medium as I write this, but > aside from a longer run time I don't expect different results. > > I also tried different blocksizes but without any better results, either. > > The error message above that I received looks really similar too the > problem in > http://www.mail-archive.com/[email protected]/msg222744.html > but there never was any reply to that email. > > I turned the fatal error inside the make_tapetype function into a > warning and added following warning inside write_one_file after it's > done writing to find out what it has done: > warn "(pattern, blocks_written, block_size) are ($pattern, > $blocks_written, $block_size)"; > This is how I found out that amtapetype doesn't know the device's > blocksize anymore after the first complete tape fill; here's the > output of that invocation: > > mecha...@kari:~$ pfexec /opt/amanda/sbin/amtapetype -b 2048k -t > sony-dgd125p /dev/rmt/0l > Applying heuristic check for compression. > (pattern, blocks_written, block_size) are (RANDOM, 92, 2097152) at > /opt/amanda/sbin/amtapetype line 184. > (pattern, blocks_written, block_size) are (FIXED, 92, 2097152) at > /opt/amanda/sbin/amtapetype line 184. > Wrote random (uncompressible) data at 3062507.68253968 bytes/sec > Wrote fixed (compressible) data at 3062507.68253968 bytes/sec > Compression: disabled > Writing one file to fill the volume. > (pattern, blocks_written, block_size) are (RANDOM, 5869, ) at > /opt/amanda/sbin/amtapetype line 184. > Wrote 0 which is less than 100MB to the device: Error writing block: > Error 0 > Wrote 0 bytes at 0 kb/sec > Writing smaller files (0 bytes) to determine filemark. > Error writing label 'amtapetype-1990590034': Error writing block: > Error 0 at /opt/amanda/sbin/amtapetype line 84. > mecha...@kari:~$ > > I also tried using non-rewindable device (/dev/rmt/0*n) even though > this is supposedly no longer necessary in 2.6.x, but the problem > remains the same. > > > Any guesses, anyone? >
Nothing solid. Why are you using the "l" low-density device? Is that the only one that does no compression? > ... pfexec /opt/amanda/sbin/amtapetype -b 2048k -t sony-dgd125p /dev/rmt/0l Anytime I see Solaris and DDS I have to mention my experience with DDS3 is that the driver can report "ready" while the tape is still rewinding. After that, while it is still rewinding, any operations fail when attempted. I had to fudge delays with sleep in some scripts, eg. changer scripts, to make them work successfully. -- Jon H. LaBadie [email protected] JG Computing 12027 Creekbend Drive (703) 787-0884 Reston, VA 20194 (703) 787-0922 (fax)
