Rodrigo Barbosa wrote:
On Fri, Jun 09, 2006 at 04:15:38PM -0400, Bowie Bailey wrote:
Rodrigo Barbosa wrote:
On Fri, Jun 09, 2006 at 03:56:36PM -0400, Bowie Bailey wrote:
I have a backup spooling onto a DLT drive. Is there any tool that will let me monitor the data throughput on the device?
Throughput on a tape drive is very variable, depending on how you are writing/reading the data to it.
So for some meaningful numbers, you would need your backup solution to provide them.
I'm just looking for raw bps flowing to the device. I don't really care about compression and such at the moment, I just want a rough idea of what the drive is doing.
There is no such thing. You "raw bps" will vary greatly depending on your blocksize and other factors.
I don't follow. The backup program is writing data to the device. Regardless of how complex that data stream is, there is a specific amount of data that is transmitted in a given period of time.
This would be like sticking a meter inline on an ethernet cable and simply counting bits.
There may or may not be a tool to do this and it may or may not be a useful measurement, but it should be possible.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, Jun 09, 2006 at 04:42:41PM -0400, Bowie Bailey wrote:
I have a backup spooling onto a DLT drive. Is there any tool that will let me monitor the data throughput on the device?
Throughput on a tape drive is very variable, depending on how you are writing/reading the data to it.
So for some meaningful numbers, you would need your backup solution to provide them.
I'm just looking for raw bps flowing to the device. I don't really care about compression and such at the moment, I just want a rough idea of what the drive is doing.
There is no such thing. You "raw bps" will vary greatly depending on your blocksize and other factors.
I don't follow. The backup program is writing data to the device. Regardless of how complex that data stream is, there is a specific amount of data that is transmitted in a given period of time.
This would be like sticking a meter inline on an ethernet cable and simply counting bits.
There may or may not be a tool to do this and it may or may not be a useful measurement, but it should be possible.
There is a setting for the tape drive (controled by an SCSI IOCTL) that is blocksize. That is what affected the performance in this particular case.
Most often values for blocksize on UNIX-ish systemas are 512 and 1024, mainly for historical reasons (and thus portability).
Sometimes you will use variable block length (not very portable, btw), and get some very weird results.
If you try reading a tape that was written on a unit with blocksize 512 on a unit set to blocksize 1024, you won't be able to read it, and will get an SCSI Error for "Illegal block size".
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
-
Bowie Bailey -
Rodrigo Barbosa