|
Home > Archive > Data Storage > September 2004 > DLT7000 block size
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
DLT7000 block size
|
|
| Gabor Melis 2004-09-15, 9:54 am |
| This box is a Dell Poweredge 2600 running Debian/Sarge with kernel 2.6.8. The
problem is with the tape:
# tar cf /dev/st0 /lib/modules/2.6.8-1-686-smp/
# tar xfv /dev/st0
<produces nothing or "Cannot allocate memory">
After heavy googling I tried passing tar the block size explicitly with -b
(for both invocations). It is not until '-b 216' that tar finally manages to
read back the archive. I can find no documentation for the Quantum DLT7000
that mentions a minimum block size and since it is a critical server I'm a
bit worried about this magic number that _seems_ to make it work.
I tested it with the default stinit.def and the one below.
Gabor Melis
# cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: MegaRAID Model: LD0 RAID5 39760R Rev: 2.48
Type: Direct-Access ANSI SCSI revision: 02
Host: scsi0 Channel: 04 Id: 06 Lun: 00
Vendor: PE/PV Model: 1x6 SCSI BP Rev: 1.1
Type: Processor ANSI SCSI revision: 02
Host: scsi0 Channel: 05 Id: 06 Lun: 00
Vendor: QUANTUM Model: DLT7000 Rev: 2561
Type: Sequential-Access ANSI SCSI revision: 02
# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x85 (DLT 35GB compressed).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
# cat /etc/stinit.def
{buffer-writes read-ahead async-writes}
manufacturer="QUANTUM" model = "DLT7000" {
scsi2logical=1
can-bsr
auto-lock=0
two-fms=0
drive-buffering=1
buffer-writes
read-ahead=1
async-writes=1
can-partitions=0
fast-mteom=1
#
# If your stinit supports the timeouts:
timeout=3600 # 1 hour
long-timeout=14400 # 4 hours
#
# Drive is backwards compatible, use older modes (e.g. from above) as
required.
mode1 blocksize=0 density=0x85 # 35GB + compression
mode2 blocksize=0 density=0x84 # 35GB, no compression
mode3 blocksize=0 density=0x83 # 20GB + compression (DLT4000 mode)
mode4 blocksize=0 density=0x82 # 20GB, no compression (DLT4000 mode)
}
| |
| Steve Cousins 2004-09-15, 9:54 am |
|
Gabor Melis wrote:
>
> This box is a Dell Poweredge 2600 running Debian/Sarge with kernel 2.6.8. The
> problem is with the tape:
>
> # tar cf /dev/st0 /lib/modules/2.6.8-1-686-smp/
> # tar xfv /dev/st0
> <produces nothing or "Cannot allocate memory">
>
> After heavy googling I tried passing tar the block size explicitly with -b
> (for both invocations). It is not until '-b 216' that tar finally manages to
> read back the archive. I can find no documentation for the Quantum DLT7000
> that mentions a minimum block size and since it is a critical server I'm a
> bit worried about this magic number that _seems_ to make it work.
There isn't really a magic number. It just needs to be consistent. You
need to use the same block size when you extract from the tape as you
did when you created the archive. I use a block size of 1024 (512 KB)
in order to get good performance:
tar cvbf 1024 /dev/tape /lib/modules
mt rewind
mkdir test
cd test
tar xvbf 1024 /dev/tape
If you don't specify a block size, GNU tar defaults to 10 KB blocks.
I'm not sure why this wouldn't work, albeit somewhat slowly.
What version of tar are you using? I think there were some problems
with some 1.12 versions of GNU tar. If that is what you have, I'd try
upgrading to 1.13. Mine is 1.13.25 and it works fine.
> # Drive is backwards compatible, use older modes (e.g. from above) as
> required.
> mode1 blocksize=0 density=0x85 # 35GB + compression
> mode2 blocksize=0 density=0x84 # 35GB, no compression
> mode3 blocksize=0 density=0x83 # 20GB + compression (DLT4000 mode)
> mode4 blocksize=0 density=0x82 # 20GB, no compression (DLT4000 mode)
> }
I think that blocksize=0 refers to variable block size.
Good luck,
Steve
--
________________________________________
______________________________
Steve Cousins, Ocean Modeling Group Email: cousins@umit.maine.edu
Marine Sciences, 208 Libby Hall http://rocky.umeoce.maine.edu
Univ. of Maine, Orono, ME 04469 Phone: (207) 581-4302
| |
| Gabor Melis 2004-09-15, 9:54 am |
| mega@hotpop.com (Gabor Melis) wrote in message news:<fb0fb805.0409140638.2acee51a@posting.google.com>...
> This box is a Dell Poweredge 2600 running Debian/Sarge with kernel 2.6.8. The
> problem is with the tape:
>
> # tar cf /dev/st0 /lib/modules/2.6.8-1-686-smp/
> # tar xfv /dev/st0
> <produces nothing or "Cannot allocate memory">
No wonder tar thinks there is nothing. If I create x.tar
$ tar cf x.tar /lib/modules/2.6.8-1-686-smp/
$ dd if=x.tar of=/dev/st0 obs=10240
$ dd of=y.tar if=/dev/st0 ibs=10240
and y.tar contains all zeros. But why?
|
|
|
|
|