dump repeatdely "stops" on PowerEdge 4400

Steve_Boley@Dell.com Steve_Boley at Dell.com
Thu Aug 1 14:14:01 CDT 2002

Apparently the st=128 sets the blocksize for the device but the dump command
defaults and is still using 10k blocksize which adds even more inefficiency
to the tape unit due to the mismatch here and causes a lot of the lagtime.
I would bet since it is very large data size that you are dealing with that
the 128 hack would give even more speed increase.

-----Original Message-----
From: Roderick McColl [mailto:Roderick.McColl at UTSouthwestern.edu]
Sent: Thursday, August 01, 2002 12:49 PM
To: Steve_Boley at exchange.dell.com
Subject: RE: dump repeatdely "stops" on PowerEdge 4400

Probably twice as fast and it just completed. I am tempted to hack up
the dump program 
to allow a blocksize of 128kB rather than 64kB to see if this will
get to go even faster!

Thanks for your help


>>> <Steve_Boley at Dell.com> 08/01/02 07:09 AM >>>
So is it completing now that it is going much faster?

-----Original Message-----
From: Roderick McColl [mailto:Roderick.McColl at UTSouthwestern.edu]
Sent: Wednesday, July 31, 2002 1:21 PM
To: Jeremy_Sheard at exchange.dell.com
Cc: Steve_Boley at exchange.dell.com
Subject: RE: dump repeatdely "stops" on PowerEdge 4400

Yes I have been in contact with Steve regarding this issue. 
I tried to use the dump command as follows, recommended by Steve
    dump -0u -b128 -f /dev/st0 /partition
and got back:
  DUMP: Please choose a record size <= 64KB.
  DUMP: The entire dump is aborted.
However, I was able to get this to work
    dump -0u -b64 -f /dev/st0 /partition
and it is going much faster (maybe twice as fast) as before. I was
if there is a version of dump available that will let me choose the
recordsize? I have also asked Steve about this.
Thanks for you help

>>> <Jeremy_Sheard at Dell.com> 07/30/02 11:00PM >>>

Have you been working with Steve B. on this issue also?  I spoke to him
about this as he has done a little more testing than I have as in
regards to
this type of issue.  The st=128 is for TAR and not for the dump command.
would remove the st=128 and just specify a -b <blocksize> when using
within the Operating System and see if the performance increases.

-----Original Message-----
From: Roderick McColl [mailto:Roderick.McColl at UTSouthwestern.edu]
Sent: Tuesday, July 30, 2002 3:28 PM
To: Jeremy_Sheard at exchange.dell.com
Subject: RE: dump repeatdely "stops" on PowerEdge 4400

I am setting the flag "st=128" in the /etc/grub.conf file. It looks like
title Red Hat Linux (2.4.9-31enterprise)
        root (hd0,1)
        kernel /vmlinuz-2.4.9-31enterprise ro root=/dev/sda6 st=128

About six months ago there was a thread on this list regarding the
issue and the recommendation was to add the "st=128" flag to the kernel
line, which would apparently override the 10 blocksize problem. Is this
the case?
Also, if I explicitly set the blocksize, according to the man page for
I cna no longer use the "-a" flag and I believe I will also have to
information about tape length, density etc to save from overwriting the
of the tape. Is this correct?
Thanks for your help

>>> <Jeremy_Sheard at Dell.com> 07/30/02 03:16PM >>>

RedHat backups using dump with default block settings can cause slow
performance.  The default block size is set too small. RedHat dump
using a default block setting of 10k cause slow performance.  This issue
present in Red Hat Linux 7.1, 7.2, and 7.3.  The block size should be
changed to 64K.  Use the  b  switch in the Dump command to change the
blocksize.  The b switch is the number of kilobytes per dump record.
Jeremy Sheard
DELL Server Support

-----Original Message-----
From: Roderick McColl [mailto:Roderick.McColl at UTSouthwestern.edu]
Sent: Tuesday, July 30, 2002 3:00 PM
To: linux-poweredge at exchange.dell.com
Subject: dump repeatdely "stops" on PowerEdge 4400

I have a 4400 with a Benchmark DLT1 tape drive. I have a large ext3
partition (203 GB used / 350 GB total) on a RAID-5 container.
I back this up using the dump command i.e.    dump 0uaf /dev/st0
The max dump speed is reported at a little over 3000kB/second which is
consistent with the reported rate for the drive (3MB/s raw). 
What I have been finding happening the last several times I have tried
dump this partition (which takes about 30 hours!!!) is that, somewhere
the middle (could be the first volume, now its the last volume) is the
command seems to simply "stop."
On this occasion it has stopped at 98 %.
Since I actually run
     dump 0uaf /dev/st0 /partition 2>&1 | tee /var/log/dump0.log
I can log into the box and look at the log. 
/var/log/dump0.log says:-
  (lots of previous lines deleted)
  DUMP: 91.49% done at 3053 kB/s, finished in 1:29
  DUMP: End of tape detected
  DUMP: Closing /dev/st0
  DUMP: Volume 3 completed at: Tue Jul 30 01:32:22 2002
  DUMP: Volume 3 61992379 tape blocks (60539.43MB)
  DUMP: Volume 3 took 5:39:07
  DUMP: Volume 3 transfer rate: 3046 kB/s
  DUMP: Change Volumes: Mount volume #4
  DUMP: Is the new volume mounted and ready to go?: ("yes" or "no")  
Volume 4 started with block 181604759 at: Tue Jul 30 11:39:12 2002
  DUMP: Volume 4 begins with blocks from inode 37109766
  DUMP: 91.79% done at 1 kB/s, finished in 1:26
  DUMP: 92.18% done at 2410 kB/s, finished in 1:22
  DUMP: 92.57% done at 2486 kB/s, finished in 1:18
  DUMP: 92.95% done at 2490 kB/s, finished in 1:14
  DUMP: 93.38% done at 2573 kB/s, finished in 1:09
  DUMP: 93.80% done at 2607 kB/s, finished in 1:05
  DUMP: 94.20% done at 2614 kB/s, finished in 1:01
  DUMP: 94.61% done at 2622 kB/s, finished in 0:56
  DUMP: 95.00% done at 2622 kB/s, finished in 0:52
  DUMP: 95.46% done at 2668 kB/s, finished in 0:47
  DUMP: 95.81% done at 2629 kB/s, finished in 0:44
  DUMP: 96.08% done at 2552 kB/s, finished in 0:41
  DUMP: 96.55% done at 2600 kB/s, finished in 0:36
  DUMP: 96.85% done at 2550 kB/s, finished in 0:33
  DUMP: 97.27% done at 2566 kB/s, finished in 0:29
  DUMP: 97.69% done at 2577 kB/s, finished in 0:24
  DUMP: 98.04% done at 2562 kB/s, finished in 0:20

It has not reported anything for more than two hours now. 
ps auxw | grep dump produces :-
root     31635  0.0  2.0 16432 13200 tty2    S    Jul29   0:37 dump 0uaf
/dev/st0 /data
root     31636  0.0  0.0  1644  408 tty2     S    Jul29   0:00 tee
root     31640  0.1  2.2 16488 14620 tty2    S    Jul29   2:03 dump 0uaf
/dev/st0 /data
root     32119  0.1  2.2 16488 14456 tty2    S    Jul29   2:15 dump 0uaf
/dev/st0 /data
root       896  0.1  2.0 16488 13088 tty2    S    Jul29   2:15 dump 0uaf
/dev/st0 /data
root      2305  0.2  2.0 16488 13392 tty2    S    11:39   0:24 dump 0uaf
/dev/st0 /data
root      2306  0.3  2.1 16576 14100 tty2    S    11:39   0:43 dump 0uaf
/dev/st0 /data
root      2307  0.3  2.1 16576 13776 tty2    S    11:39   0:44 dump 0uaf
/dev/st0 /data
root      2308  0.3  2.0 16576 13276 tty2    S    11:39   0:45 dump 0uaf
/dev/st0 /data
There is nothing in /var/log/messages to indicate that some event
occured to
force a stop.
Does anyone have any idea what might cause this behavior? This is
very worrisome if
I can't make a backup!!! 
By the way, the tape I am using is brand new, Maxell DLT 40/80. I have
run the cleaning tape.

More information about the Linux-PowerEdge mailing list