Hardware compression pb

[Claude]

Hi to all !

I got a problem with "Backup Exec"...
Everything works fine except that the backups work at les than 20 MB/Min...
Then the duration is about 30 hours for a 20 GB Backup.

When I go in the Hardware compression parameters, the Blocks are set to 2K.
Then, if I launch my job, it turns to less than 20 MB/Min.

I reset to the defaults parameters to set the block's size to 32K, launch
my job and it goes fine with more than 300 MB/Min.

The job is then rescheduled at night... and, again, it works at less than
20 MB/Min... The block's size return to 2K... Why ?

Even if i delete and recreate the job, it's still the same.

Any idea to enforce and keep the block'size to 32K ?

Thanks in advance !!!

Claude.

 

[Arno Wagner]

Hi to all !

I got a problem with "Backup Exec"...
Everything works fine except that the backups work at les than 20 MB/Min...
Then the duration is about 30 hours for a 20 GB Backup.

When I go in the Hardware compression parameters, the Blocks are set to 2K.
Then, if I launch my job, it turns to less than 20 MB/Min.

I reset to the defaults parameters to set the block's size to 32K, launch
my job and it goes fine with more than 300 MB/Min.

The job is then rescheduled at night... and, again, it works at less than
20 MB/Min... The block's size return to 2K... Why ?

Might be a ''trashing'' issue: With 2k Blocks you get waits and
rewinds, with 32K you get streaming.

Arno

 

[Claude]

Arno Wagner <[email protected]> écrivait
A "trashing" issue ? Sorry but what do you mean exactly ?
And I still don't understand why this parameter changes by itself (or by
Backup Exec ?) ?

Claude.

 

[Arno Wagner]

Arno Wagner <[email protected]> écrivait news:[email protected]:

A "trashing" issue ? Sorry but what do you mean exactly ?
And I still don't understand why this parameter changes by itself (or by
Backup Exec ?) ?

Sorry. Trashing originally (I think) means that a ressource
that has to be gotten with large effort to be used
after a short use becomes useless and has to be thronw away.
Repeat to get "trashing". The system then spends most of its
time getting the ressource(s).

In your case that would mean that the drive writes 2K, but
the tape is far faster than the delay it takes to get the next
2k to it. Then it has to stop and rewind (i.e. get the ressource
"position for the next 2k" to the drivehead), which takes
massively longer than writing 2k. In the end your drive does
e.g. 99.9% stop-rewind-seek and 0.1% writing of data,
slowing it down by a factor of 1000. It is a well knowen effect
in some areas, e.g. cache memory.

The name derives from the fact that a ressource that was
obtained at great effort immediately becomes unuseful
again ('trash').

I have no idea why your system keeps changing the block size
parameter, but I have seen trashing on a DAT tape. The solution
was to add a large buffer between the tape and the data-stream
generator (tar). Then the buffer fills while the tape is rewinding
and the tape can get the whole buffer contents to tape in one go.
This allows to get the average write-speed up to the data-generation
speed.

Arno

 

[John Turco]

Sorry. Trashing originally (I think) means that a ressource
that has to be gotten with large effort to be used
after a short use becomes useless and has to be thronw away.
Repeat to get "trashing". The system then spends most of its
time getting the ressource(s).

In your case that would mean that the drive writes 2K, but
the tape is far faster than the delay it takes to get the next
2k to it. Then it has to stop and rewind (i.e. get the ressource
"position for the next 2k" to the drivehead), which takes
massively longer than writing 2k. In the end your drive does
e.g. 99.9% stop-rewind-seek and 0.1% writing of data,
slowing it down by a factor of 1000. It is a well knowen effect
in some areas, e.g. cache memory.

The name derives from the fact that a ressource that was
obtained at great effort immediately becomes unuseful
again ('trash').

I have no idea why your system keeps changing the block size
parameter, but I have seen trashing on a DAT tape. The solution
was to add a large buffer between the tape and the data-stream
generator (tar). Then the buffer fills while the tape is rewinding
and the tape can get the whole buffer contents to tape in one go.
This allows to get the average write-speed up to the data-generation
speed.

Arno

Hello, Arno:

The technical term for this "stop-rewind-seek" phenomenon, is
"shoe-shining." I, myself, have encountered it, on cheap Iomega
QIC-80 and "Ditto Max" tape drives.


Cordially,
John Turco <[email protected]>

 

[Arno Wagner]

[...]

Hello, Arno:

The technical term for this "stop-rewind-seek" phenomenon, is
"shoe-shining." I, myself, have encountered it, on cheap Iomega
QIC-80 and "Ditto Max" tape drives.

Aha, interesting. I have never heard this, but it does make
sense. Thanks!

Arno

 

[Folkert Rienstra]

Rotflol.



Hello, Arno:

The technical term for this "stop-rewind-seek" phenomenon, is

"shoe-shining."

That is only a single word, John. Unfit for our blabbermouth Arnie.
And so difficult to spike with typos.