Very Computer

Hi all,

I've a SUN Enterprise 420R (Solaris 8) and a SUN 12-24 GByte 4mm DDS-3
Tape Drive. I tried to backup a DiskSuite Submirror (about 10 GB) with
ufsdump to a tape (Tape: HP dds-3 data catridge, 24 GB compressed), but
I get the follwing ouput:

   DUMP: Writing 32 Kilobyte records
   DUMP: Date of this level 0 dump: Wed Oct 20 20:23:04 2004
   DUMP: Date of last level 0 dump: the epoch
   DUMP: Dumping /dev/md/rdsk/d2 to /dev/rmt/0.
   DUMP: Mapping (Pass I) [regular files]
   DUMP: Mapping (Pass II) [directories]
   DUMP: Estimated 21053968 blocks (10280.26MB).
   DUMP: Dumping (Pass III) [directories]
   DUMP: Dumping (Pass IV) [regular files]
[...]
   DUMP: 98.91% done, finished in 0:02
   DUMP: End-of-tape detected
   DUMP: Tape rewinding
   DUMP: 99.15% done, finished in 0:01
   DUMP: Change Volumes: Mount volume `#2' on `<Hostname>:/dev/rmt/0'
   DUMP: NEEDS ATTENTION: Is the new volume (#2) mounted on
`<Hostname>:/dev/rmt/0' and ready to go?: ("yes" or "no")

I'm using the follwing command:

# ufsdump 0f /dev/rmt/0 /dev/md/rdsk/d2

I also tried /dev/rmt/0c, but I get the same ouput.

Thank you for any help

Julian

Julian,
there are two things to know here. Firstly, know what
sort of data you are backing up. jpgs (for example) do
not compress much if at all because of the underlying
data structure(s). Secondly, if you try to dump compressed
data to the compression device (/dev/rmt/*c..) then you
will actually use more tape than you expected.

Another thing to remember is that the manufacturer's
"12-24Gb" is based on dumping text (ascii) to the
compression device, and letting the device's builtin
compression algorithms go to work.

Finally, if you can't stream to the tape drive then you
will incur a penalty in terms of the amount of tape used
because the motors will be stopping and starting more
frequently, thereby using more tape.

Of course, you could have a bodgy tape too ;) check your
/var/adm/messages file for any indication of write errors
or read errors. If you see any then you should consider
dumping that tape in the round filing cabinet.

best regards,
mcbofh

It looks like your tape does only use 12GB per tape.
Try also the devices /dev/rmt/0h and /dev/rmt/0u, maybe the tape
driver then manages to turn the high compression on.

--
Michael Tosch
IT Specialist
HP Managed Services
Technology Solutions Group
Hewlett-Packard GmbH
Phone: +49 2407 575 313
Mail: michael.tosch:hp.com

First, thank you for your answer!

Quote:> there are two things to know here. Firstly, know what
> sort of data you are backing up. jpgs (for example) do
> not compress much if at all because of the underlying
> data structure(s).

Yes ;) I want to backup lots of jpgs, 10 Gbyte of images,
nothing else.

Quote:> Secondly, if you try to dump compressed
> data to the compression device (/dev/rmt/*c..) then you
> will actually use more tape than you expected.

> Another thing to remember is that the manufacturer's
> "12-24Gb" is based on dumping text (ascii) to the
> compression device, and letting the device's builtin
> compression algorithms go to work.

So, it is possible that 10 Gbyte of images are too much
for a tape, that can hold 12 Gbyte "uncompressed" ascii
or 24 GByte "compressed" ascii?

Quote:> Finally, if you can't stream to the tape drive then you
> will incur a penalty in terms of the amount of tape used
> because the motors will be stopping and starting more
> frequently, thereby using more tape.

hmm.. perhaps i should buy a bigger tape drive...
But this is at the moment not possible.
Is there another possibility for me. I don't want to get up
at night to change a tape, while my backup-script via cron
is running and waiting for a new tape ;)

Quote:> Of course, you could have a bodgy tape too ;) check your
> /var/adm/messages file for any indication of write errors
> or read errors. If you see any then you should consider
> dumping that tape in the round filing cabinet.

There were no errors in /var/adm/messages. the tape works without
any errors.

Julian

Quote:>Hi all,

>I've a SUN Enterprise 420R (Solaris 8) and a SUN 12-24 GByte 4mm DDS-3
>Tape Drive. I tried to backup a DiskSuite Submirror (about 10 GB) with
>ufsdump to a tape (Tape: HP dds-3 data catridge, 24 GB compressed), but
>I get the follwing ouput:

>   DUMP: Writing 32 Kilobyte records
>   DUMP: Date of this level 0 dump: Wed Oct 20 20:23:04 2004
>   DUMP: Date of last level 0 dump: the epoch
>   DUMP: Dumping /dev/md/rdsk/d2 to /dev/rmt/0.
>   DUMP: Mapping (Pass I) [regular files]
>   DUMP: Mapping (Pass II) [directories]
>   DUMP: Estimated 21053968 blocks (10280.26MB).
>   DUMP: Dumping (Pass III) [directories]
>   DUMP: Dumping (Pass IV) [regular files]
>[...]
>   DUMP: 98.91% done, finished in 0:02
>   DUMP: End-of-tape detected
>   DUMP: Tape rewinding
>   DUMP: 99.15% done, finished in 0:01
>   DUMP: Change Volumes: Mount volume `#2' on `<Hostname>:/dev/rmt/0'
>   DUMP: NEEDS ATTENTION: Is the new volume (#2) mounted on
>`<Hostname>:/dev/rmt/0' and ready to go?: ("yes" or "no")

>I'm using the follwing command:

># ufsdump 0f /dev/rmt/0 /dev/md/rdsk/d2

>I also tried /dev/rmt/0c, but I get the same ouput.

>Thank you for any help

>Julian

You could try using a different block size. try :

ufsdump 0bf 96 /dev/rmt/0 /dev/md/rdsk/d2

I think 96 is optimal for 4mm tapes

-Raf

That is the correct device to use to get hardware compression.  Have you
set the jumper correctly on the drive to actually enable compression?

We use a block size of 126 here, which the man page says is the highest
available for most tape drives.  In addition to fitting more on to the
tape, you will find that the dump takes less time.

--
Tom Schulz

Thank you all for the replies!!!

A short summary:

a) same result if i use /dev/rmt/0u, 0, 0c, 0h

b) over night i will try a different blocksize:
    ufsdump 0bf 96 /dev/rmt/0 /dev/md/rdsk/d2 or
    ufsdump 0bf 126 /dev/rmt/0 /dev/md/rdsk/d2

    And what about the restore? Can i just restore
    a dump with a blocksize of 126 the same way or is
    there anything special? I want to restore
    a dump with ufsrestore by hand, if a disk fails.

c) I've an external tape drive, i didn't change
anything on the drive directly (ie. the jumpers).
I just attached the device and follwed the instructions
in the installation manual to get the drive work.
I also didn't find any information about a jumper for
the hardware compression.

Julian

My DEC/Sony DDS2 drive has a small map of the jumpers and their functions.
It's necessary to remove the drive from the enclosure to see the jumpers
and the map, if there is one.  In any case the product manual should have
the necessary information.

Perhaps this would be of assistance:

http://sunsolve.sun.com/handbook_pub/Devices/Rmvbl_Media_Options/RMVB...

Thanks for the link, but there is nothing about hardware compression.
I know from the installation manual that some jumpers exists, but they
are there to set the SCSI-ID.

Julian

Likes your data is not terribly compressible.

Wow  99.15% done.. how unlucky is that?

Stuart
Dr. Stuart A. Weinstein
Ewa Beach Institute of Tectonics
"To err is human, but to really foul things up requires a creationist"        

"Creationists aren't impervious to Logic: They're oblivious to it."

Quote:>Thank you all for the replies!!!

>A short summary:

>a) same result if i use /dev/rmt/0u, 0, 0c, 0h

>b) over night i will try a different blocksize:
>    ufsdump 0bf 96 /dev/rmt/0 /dev/md/rdsk/d2 or
>    ufsdump 0bf 126 /dev/rmt/0 /dev/md/rdsk/d2

>    And what about the restore? Can i just restore
>    a dump with a blocksize of 126 the same way or is
>    there anything special? I want to restore
>    a dump with ufsrestore by hand, if a disk fails.

The Solaris ufsrestore will figure out the block size on it's own.  If you
ever have to deal with other systems, some of them need to have the block
size specified on the restore command line.  It is always a good idea to
do a test restore every so often to make sure that everything is working.

Quote:>c) I've an external tape drive, i didn't change
>anything on the drive directly (ie. the jumpers).
>I just attached the device and follwed the instructions
>in the installation manual to get the drive work.
>I also didn't find any information about a jumper for
>the hardware compression.

On would hope that if you got the drive from Sun, everything would be set
correctly at the factory.  Some drives have a jumper or switch to disable
compression, but I doubt that Sun would ship it with compression disabled.
/dev/rmt/0c is the device for compression, but if your data can not be
compressed, you would see little difference.  I would expect some difference,
but possibly a very small difference.

Quote:>Julian

--
Tom Schulz

The same problem if i use a blocksize of 126 or 96 or the default
(don't know how much).
The tape is to small or to much data ;)

Julian

: The same problem if i use a blocksize of 126 or 96 or the default
: (don't know how much).
: The tape is to small or to much data ;)

  Good point, can you give us info on the tape you're
using?

  lenght? (60, 90, 120 meters, etc)
  type?   (DDS 1, 2, 3, etc)

--
Barry Keeney
Chaos Consulting
email barryk<at>chaoscon.com

"Rap is Square Dancing gone terribly, terribly Wrong...."

JPG format is already compressed far better than the modest
compression hardware/firmware in your drive.  If compression
is in fact enabled, then your drive will attempt to recompress
the already-compressed data and will actually GROW the data
size.

It sounds like that is happening (i.e., only 10GB of data on
a 12GB tape).

Find out what the non-compress device is for your system.
Probably /dev/rmt/0l.  Use that, and I bet the 10GB will
fit.

However, you're right at the edge of capacity in any case;
why not just use two tapes, as ufsdump is already offering
to do for you?  The tapes are (reletively) cheap...

FYI, more sophisticated/recent drives (LTO for sure, SDLT I
think) will autodetect pre-compressed data streams and decline
to recompress the data.  But that's way more expensive hardware
than you're interested in at the moment...

-Jay-