On Thu, 26 Jan 2006, Kai Makisara wrote:
You did not say whether the drive was in fixed block mode ('mt status'
tell nonzero block size) of variable block mode. The Seagate (now Quantum)
drives usually wake up in fixed block mode with 1024 byte block size. I am
assuming this is the case here.
Close, but with 512 byte fixed blocks by default:
RHEL4# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=1, block number=0, partition=0.
Tape block size 512 bytes. Density code 0x47 (TR-5).
Soft error count since last status=0
General status bits on (81010000):
EOF ONLINE IM_REP_EN
Compression seems to be enabled because you get speeds that exceed the 3.5
MB/s native speed of the drive. You are measuring here more the speed of
the drive's processor than the tape reading performance. However, this
does not invalidate the results of these tests.
Good point; a file entirely comprised of zeros should compress very
well. So I repeated the experiments with compression off. First,
with direct I/O
RHEL4# time dd if=/dev/nst0 of=/dev/null bs=1k
1000000+0 records in
1000000+0 records out
real 10m34.332s
user 0m1.136s
sys 0m16.209s
then again without it
RHEL4# time dd if=/dev/nst0 of=/dev/null bs=1k
1000000+0 records in
1000000+0 records out
real 4m47.364s
user 0m0.655s
sys 0m5.780s
I repeated these tests with a HP DAT40 connected to a LSI Logic 53c1010
HBA. The kernel was 2.6.16-rc1-git4.
The tests in fixed block mode showed similar behaviour with slightly
different times (6m10 vs 1m6). (In variable block mode the time was 6m10
with both try_direct_io=1 and try_direct_io=0).
So are you saying that the best time in the experiments you did (1m6)
is without direct I/O using fixed blocks? This is nearly six times
faster than fixed blocks with direct I/O, or variable blocks in either
case.
Your analysis here is correct. This is also the case I mentioned in
another message where I said that disabling direct i/o increases speed in
fixed block mode: the read() and write() byte counts are very small.
The problem is that this case is testing something that you should never
do with a tape. No even half-decent tape application does this. The
nearest I know is tar with the default 10 kB block size.
Well, the default mode of the tape drive when it comes up is a 512
byte fixed block size. tar, cpio and dump all use fixed block sizes
by default. So it seems that the default behavior is "something that
you should never do with a tape". I would argue that this is a
problem.
I did the test again with larger blocks (the buffer in the tape drive
is 32K), first without direct I/O
RHEL4# cat /sys/bus/scsi/drivers/st/try_direct_io 0
RHEL4# time dd if=/dev/nst0 of=/dev/null bs=32k
31250+0 records in
31250+0 records out
real 2m30.688s
user 0m0.028s
sys 0m2.871s
then again with direct I/O
RHEL4# time dd if=/dev/nst0 of=/dev/null bs=32k
31250+0 records in
31250+0 records out
real 2m30.687s
user 0m0.063s
sys 0m0.677s
So in this case, performance is no worse or better with direct I/O
than without.
This is a more realistic test. The 32 kB i/o size is large enough for many
drives. In another message you prove this for the DAT72 because you did
not get better speed with 64 kB i/o size. (The drive manufacturers usually
provide a suggestion for the optimal i/o size.)
Granted, but in the best possible case, using direct I/O gives the
same performance as not using it; and in all other cases it is much
worse. Can you describe a configuration I can test where direct I/O
makes the performance better?
Chip
--
Charles M. "Chip" Coldwell
Senior Software Engineer
Red Hat, Inc
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
