Exabyte 8500 w/add-on compression
2007-12-25 8:28:00
> I've got an R-Squared Exabyte 8500 with an add-on compression unit (it
> has a nice LCD display showing the mode, status, compression ratio,
> error rate, etc.). I'm trying to dump a *large* filesystem (2.7 GB,
> mostly gzipped data files). The problem is that I'm hitting the end
> of the tape before the dump completes. Since I'm dumping in 8500
> mode, I should be getting closer to 5GB on the tape.
And followed up with:
> 1) SunOS has a file size limit of 2GB, but I really am hitting the end
> of the tape. The LCD display counts down the remaining tape
> capacity, and when it hits zero, the dump fails with something like
> "error writing to tape". Subsequent attempts to write to the tape
> fail with the same error.
>
> 2) I'm using the command:
>
> dump 0bsdf 200 12000 54000 /dev/nrst0 /dev/md1a
>
> I think 200 is about the largest block size I could get to work.
>
> The size and density multiply out to better than 7GB.
>
> Although I'm writing to rst0, the drive is in "8500, compressed"
> mode--it says so on the LCD panel. The bit about adding 8 to get
> 8500 mode is only necessary when the drive doesn't default to 8500
> mode.
>
> 3) Most of the files I'm dumping are gzipped, so I don't expect the
> built-in compression to do much. In fact, it reports a compression
> ratio of 1.1 before the dump dies. Without compression, though, I
> should get nearly 5GB on the tape. I'm only getting half that.
>
> 4) This isn't an 8500C, it's an 8500 with an add-on compression unit.
> The kernel mod for the 8500C won't help, and only implements
> selection of density and compression by specifying the appropriate
> device name.
>
> It seems to me that there are only two possibilities: the unit is
> defective (not really using 8500 mode, for example) or dump is wasting
> half the tape. The throughput--reported by the LCD panel, again--was
> an average of 300 KB/s. Is streaming a problem with these drives? Is
> this slow enough to waste half the tape?
I received *many* replies, most suggesting:
-turn off the compression
-use a smaller block size; 126 is the maximum supported
-use /dev/rst8 instead of /dev/rst0
Turning off compression doesn't help--it just causes the dump to use
more tape.
Dropping the block size from 200 to 126 doesn't help--it just slows
down the dump considerably. I've been using 200 for years, and have
had no problems dumping or restoring.
Switching from /dev/rst0 to /dev/rst8 did the trick. Even though the
drive was claiming it was writting in 8500 mode, it wasn't. Even
though this is documented in the "st" man page, I consider this a bug
since the drive incorrectly reported the mode it was in.
My dumps are now achieving a sustained transfer rate of over 500 KB/s!
Thanks for all the help.
--
Dave Sill (de5@ornl.gov) Computers should work the way beginners
Martin Marietta Energy Systems expect them to, and one day they will.
Workstation Support -- Ted Nelson
Comments
Got something to say?
You must be logged in to post a comment.
