I have a DLT IV drive that I cannot get to stream with amanda. With a little
bit of experimentation, I have found that it will stream with tar if I set the
block size to 128KB. However, amanda only seems to support block sizes of
32kb. The constant rewind/seek motion of the tape is rough on
On Fri, Jan 14, 2005 at 11:23:19AM -0800, Dan Rich wrote:
I have a DLT IV drive that I cannot get to stream with amanda. With a
little bit of experimentation, I have found that it will stream with tar if
I set the block size to 128KB. However, amanda only seems to support block
sizes of
On Fri, 2005-01-14 at 11:23 -0800, Dan Rich wrote:
I have a DLT IV drive that I cannot get to stream with amanda.
I ran into the same problem. I solved it (inelegantly, but solved with
no source code futzing) by running the backup with no tape in the drive,
then later running amflush when the
Dan Rich wrote:
I have a DLT IV drive that I cannot get to stream with amanda. With a
little bit of experimentation, I have found that it will stream with tar
if I set the block size to 128KB. However, amanda only seems to support
block sizes of 32kb. The constant rewind/seek motion of the
Hi, Jon,
on Freitag, 14. Jänner 2005 at 20:44 you wrote to amanda-users:
JL It is not a patch, its a feature.
JL But it must be specified at configure time, then compiled.
JL Check the amanda man page for blocksize.
To be precise, please check the latest version of the amanda.8-manpage
at
of the amanda.8-manpage
at http://www.amanda.org/docs/amanda.8.html, the html-version contains
the most up-to-date version.
Thanks, I just recompiled it. Unfortunately, I can't hear whether or
not my tape drive at home is streaming from the office :) Hopefully
this will work and I can still
Are you sure that the amount of holding disk space you have,
minus 50%, is sufficient to hold those level 0's?
Yes. They dump and fit. I have 25G of holding space and only dump
10G or so.
The whats.NEW is actually quite old. Note at the top of the
document it indicates these are new
Instead, it says, if a backup is level 0, can it be buffered on
the holding disk. If the reserve parameter is set to 100, then
100% of the holding disk space can be used only for incrementals.
All level 0's will go straight to tape. If the reserve is set to
25%, then that portion can
On Thu, Jun 17, 2004 at 08:02:59AM -0400, Greg Troxel wrote:
Instead, it says, if a backup is level 0, can it be buffered on
the holding disk. If the reserve parameter is set to 100, then
100% of the holding disk space can be used only for incrementals.
All level 0's will go straight
On Thu, 2004-06-17 at 08:03, Jon LaBadie wrote:
If there is no tape present (or the tape drive fails during dumping),
Amanda switches to degraded mode. In degraded mode, level-0 dumps
are not allowed.
Don't think so. According to the ChangeLog in the Amanda source:
1998-06-28
I have Amanda configured to do all its backups (local and net) to disk.
I set the reserved parameter to 0 -- that will make it do complete
backups, right? (As opposed to degraded mode)
And if I run amflush I'll have complete backups on tape of everything in
the disklist, right?
long story
A
Glenn English wrote:
I have Amanda configured to do all its backups (local and net) to disk.
I set the reserved parameter to 0 -- that will make it do complete
backups, right? (As opposed to degraded mode)
And if I run amflush I'll have complete backups on tape of everything in
the disklist,
On Wed, Jun 16, 2004 at 02:27:07PM -0600, Glenn English wrote:
I have Amanda configured to do all its backups (local and net) to disk.
I set the reserved parameter to 0 -- that will make it do complete
backups, right? (As opposed to degraded mode)
And if I run amflush I'll have complete
Hi, Glenn,
on Donnerstag, 03. Juni 2004 at 06:51 you wrote to amanda-users:
GE Jon implied that hdparm may be just kidding about this. hdparm -Tt gives
GE the following:
GE
GE /dev/hda:
GE Timing buffer-cache reads: 2800 MB in 2.00 seconds = 1399.51 MB/sec
GE Timing buffered disk
Hi, Stefan G. Weichinger,
on Donnerstag, 03. Juni 2004 at 09:12 you wrote to amanda-users:
SGW Hi, Glenn,
SGW on Donnerstag, 03. Juni 2004 at 06:51 you wrote to amanda-users:
GE I looked at another system: an old Dell server downstairs with a Maxtor
GE PCI IDE card and a 2 or 3 year old Maxtor
Glenn English [EMAIL PROTECTED] writes:
On Wed, 2004-06-02 at 10:59, Jon LaBadie wrote:
I doubt there is any tapedrive that is too fast for your
disk drives.
I thought so too. But when dump is running from one disk to the other,
it reports speeds about 20% higher (~10MB/s) than it does
Glen
I'd check the logic in the kernel code that checks for 80 way cables etc
etc. When I last looked at 2.4.19 it was doing some weird stuff - do the
checks then reset the flag where the bit table for the capabilities of
the drive is set. As opposed to reset, then do the checks!
I know you
On Thursday 03 June 2004 03:26, Stefan G. Weichinger wrote:
Hi, Stefan G. Weichinger,
on Donnerstag, 03. Juni 2004 at 09:12 you wrote to amanda-users:
SGW Hi, Glenn,
SGW on Donnerstag, 03. Juni 2004 at 06:51 you wrote to
amanda-users:
GE I looked at another system: an old Dell server
, is hopeless, streaming-wise.
I know I could do amdumps and then amflushes at 3:00 AM, but if I could
get Amanda to wait for all the dumps to come in before writing to tape,
I think things would be OK. I wouldn't mind dedicating an IDE drive as
the holdingdisk, but I'd hate to have to buy a 60GB SCSI
disk on a dedicated Amanda server like ours. The
only exception I can think of is raw platter RPMs; I don't know
whether that'd make the difference between keeping your DLT
streaming and not (with our lowly DDS3, it's not exactly an issue
:-/)
--
| | /\
|-_|/ Eric Siegerman, Toronto, Ont
On Wed, 2004-06-02 at 10:59, Jon LaBadie wrote:
I doubt there is any tapedrive that is too fast for your
disk drives.
I thought so too. But when dump is running from one disk to the other,
it reports speeds about 20% higher (~10MB/s) than it does when running
from disk to tape (~8MB/s). I can
On Wednesday 02 June 2004 15:51, Glenn English wrote:
On Wed, 2004-06-02 at 10:59, Jon LaBadie wrote:
I doubt there is any tapedrive that is too fast for your
disk drives.
I thought so too. But when dump is running from one disk to the
other, it reports speeds about 20% higher (~10MB/s) than
On Wed, Jun 02, 2004 at 01:51:26PM -0600, Glenn English wrote:
On Wed, 2004-06-02 at 10:59, Jon LaBadie wrote:
I doubt there is any tapedrive that is too fast for your
disk drives.
I thought so too. But when dump is running from one disk to the other,
it reports speeds about 20% higher
On Wed, 2004-06-02 at 14:12, Gene Heskett wrote:
Any current ide drive can do 30+ Mb/sec if left
alone by other tasks, often quite a ways on the + side.
Is that just a burst out of the cache, or can they read dis-contiguous
files, seek around to other files, wait for latency, and write all at
Hi, Glenn,
on Donnerstag, 03. Juni 2004 at 00:21 you wrote to amanda-users:
GE On Wed, 2004-06-02 at 14:12, Gene Heskett wrote:
There is also an algorythm string in amanda.conf that adjusts the
dumporders a bit, I have mine set to to the largest dump first, so
that once its done, there is
On Wed, Jun 02, 2004 at 04:21:35PM -0600, Glenn English wrote:
On Wed, 2004-06-02 at 14:12, Gene Heskett wrote:
Any current ide drive can do 30+ Mb/sec if left
alone by other tasks, often quite a ways on the + side.
Is that just a burst out of the cache, or can they read dis-contiguous
On Wednesday 02 June 2004 18:21, Glenn English wrote:
On Wed, 2004-06-02 at 14:12, Gene Heskett wrote:
Any current ide drive can do 30+ Mb/sec if left
alone by other tasks, often quite a ways on the + side.
Is that just a burst out of the cache, or can they read
dis-contiguous files, seek
On Wednesday 02 June 2004 18:48, Jon LaBadie wrote:
On Wed, Jun 02, 2004 at 04:21:35PM -0600, Glenn English wrote:
On Wed, 2004-06-02 at 14:12, Gene Heskett wrote:
Any current ide drive can do 30+ Mb/sec if left
alone by other tasks, often quite a ways on the + side.
Is that just a burst
On Wednesday 02 June 2004 19:00, Stefan G. Weichinger wrote:
Hi, Jon,
on Donnerstag, 03. Juni 2004 at 00:48 you wrote to amanda-users:
JL On Solaris x86, one thing that terribly degrades IDE disk
JL performance is if the driver does not use dma but uses pio mode.
JL There are even reports of
On Wed, Jun 02, 2004 at 09:52:55PM -0400, Gene Heskett wrote:
The ideal situation would be to have the backup thats
being optionally gzipped ...
Gene's mention of compression reminded me. If you are using
disk drive compression you have to feed data at a higher rate
to the drive than if it
--On Wednesday, June 02, 2004 23:19:03 -0400 Jon LaBadie [EMAIL PROTECTED] wrote:
On Wed, Jun 02, 2004 at 09:52:55PM -0400, Gene Heskett wrote:
The ideal situation would be to have the backup thats
being optionally gzipped ...
Gene's mention of compression reminded me. If you are using
On Wed, 2004-06-02 at 17:07, Frank Smith wrote:
If it's linux, try using hdparm to verify the modes and speed of your
disk. Like Jon says, a good drive can have terrible performance if
it is running in the wrong mode.
hdparm is a nifty addition to my system monitoring toolkit (top, gnome's
On Wed, Jun 02, 2004 at 10:45:00PM -0500, Frank Smith wrote:
--On Wednesday, June 02, 2004 23:19:03 -0400 Jon LaBadie [EMAIL PROTECTED] wrote:
On Wed, Jun 02, 2004 at 09:52:55PM -0400, Gene Heskett wrote:
The ideal situation would be to have the backup thats
being optionally gzipped
# B - biggest bandwitdh
# try BTBTBTBTBTBT if you are not holding
# disk constrained
# BUT, if you want streaming, start with the big ones and work
down
---
Maybe I should change the first 5 or 6
Resent on the list Jon, I'm bouncing again
On Friday 30 May 2003 04:07, Jon LaBadie wrote:
On Fri, May 30, 2003 at 03:15:54AM -0400, Gene Heskett wrote:
Hi everybody;
Now the client is a bit slow, a 500mhz K6-III, so I expected the
level 0's this would cause would take a while. This also
Hi everybody;
I've been rsync'ing those pieces of the firewall I consider precious
for the last 2 years, and backing up this rsync'd mirror.
Tonight, I figured it was time I actually learned a bit about
client-server relationships, so I redid the disklist, and installed
the 20030529 snapshot
Gene Heskett wrote:
Now the client is a bit slow, a 500mhz K6-III, so I expected the level
0's this would cause would take a while. This also brought my
disklist entries up to 44. The string that controls the dumporder in
amanda.conf:
dumporder
On Wed, 12 Dec 2001, Mihai Lozoveanu wrote:
Does anyone know how to modify the buffering ot the taper so that I can achive
tape streaming. I'm using an dlt8000 tape on an enterprise e250 sun server. When
Are you using a holding disk? Or backing up direct to tape?
-Mitch
Mitch == Mitch Collinsworth [EMAIL PROTECTED] writes:
Yes, I'am using 20G for holding disk. I had two files produced by amdump each
one 9G. The taper doesn't achieve streaming when write them to the tape (and
the rate is around 4MB/s instead of 5.9MB/s which is nominal). I tried
Hi,
Does anyone know how to modify the buffering ot the taper so that I can achive
tape streaming. I'm using an dlt8000 tape on an enterprise e250 sun server. When
write the same files to the tape using tar with blocking factor 126 or 256 the
tape gets into full streaming.
The tapebufs
Joe McGuckin [EMAIL PROTECTED] writes:
I'm using Amanda on FreeBSD 4.3 with a DLT7000.
I notice when dumping that the DLT drive does not stream continously.
Are there options to taper to make it go faster ?
Thanks,
Joe
Joe,
Have you checked the basic stuff?
Is the holding disk
I'm using Amanda on FreeBSD 4.3 with a DLT7000.
I notice when dumping that the DLT drive does not stream continously.
Are there options to taper to make it go faster ?
Thanks,
Joe
, taper is already doing a really good job. If the drive
is not streaming, you may need to look elsewhere (how fast taper can
read from the holding disk, how fast the controller can feed the drive,
other bus contention, termination problems, cable problems, etc).
Joe
John R. Jackson, Technical
I have a FreeBSD system running Amanda 2.4.2 with a DLT7000 tape drive.
I notice that the drive doesn't stream continously. The tape shuttles back and
forth.
Is there a way to maximize tape drive throughput so that the tape drive will
stream continously?
Thanks,
Joe
DUMP SUMMARY:
44 matches
Mail list logo
