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? Kind regards, Filip -- My weblog: http://blog.sysfs.net/
