ADSM-L

Re: HP-UX restore problem

2002-05-15 17:37:29
Subject: Re: HP-UX restore problem
From: Zlatko Krastev <acit AT ATTGLOBAL DOT NET>
Date: Thu, 16 May 2002 00:14:53 +0300
Are you able using "dd if=/dev/zero" to create file of this size. If you
can problem is in TSM. But until then you cannot be sure there is
something in HP-UX settings.

Zlatko Krastev
IT Consultant




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        HP-UX restore problem

We recently ran into an odd problem restoring files to an HP-UX 11.0
system with 4.1.2.0 client software. The TSM server is at 4.2.1.9 and
runs under OS/390. We received the following error messages:

05/05/02   11:57:26 ANS4025E Error processing '/db/tjfrev6/MUMPS.EXT':
file exceeds user or system file limit
05/05/02   11:57:26 ANS4025E Error processing '/db/tjfrev6/MUMPS.EXT':
file exceeds user or system file limit
05/05/02   12:56:15 ANS4025E Error processing '/db/tjfserv6/MUMPS.EXT':
file exceeds user or system file limit
05/05/02   12:56:15 ANS4025E Error processing '/db/tjfserv6/MUMPS.EXT':
file exceeds user or system file limit

We discovered that each of the restored files was 2,147,483,136 bytes
long. The dsmsched.log entries for the backups of the files were still
around, and showed a length of 2,147,483,647 bytes for each of the files,
which is 511 bytes more than the length of each of the restored files. The
original length turns out to be 2**31-1. The HP-UX administrator contacted
HP, who had him check a variety of system settings. After reviewing the
settings HP was adamant that there was nothing in the system configuration
to prevent TSM from writing files of the original length.

The restore process had one unusual feature. When the files were backed up
/db/tjfrev6 and /db/tjfserv6 were file systems. When the files were
restored
/db/tjfrev6 and /db/tjfserv6 were ordinary directories within the /db file
system.

The loss of 511 bytes had no visible effect on the application that used
the
files. This is not quite as surprising as it sounds. The application
treats
each of its database files as a collection of 2048 byte blocks. The
original
length would have included 2047 bytes that did not fit into a block. Even
though we dodged the bullet in this case, we are worried about running
into
this problem in the future. Is this a known problem?
<Prev in Thread] Current Thread [Next in Thread>