Andrew,
Perform the following action to see what is wrong with the volume:
audit vol /tsmstg/001E.BFS fix=yes
best regards,
Kurt
-Oorspronkelijk bericht-
Van: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] Namens Andrew
Carlson
Verzonden: woensdag 12 mei 2010 4:32
Aan: ADSM-L
You probably have database damage, which can result from running the server
without the safeguards recommended in the Admin Guide manual. Running Query
CONtent ... DAmaged=Yes on the volume may reveal the files in trouble.
Richard Sims http://people.bu.edu/rbs/
Leandro -
The problem you're dealing with is a personnel management one, which can't be
solved by technology alone. The management there is the only avenue of
solution.
Technology can help, though. You can harvest records from the dsmaccnt.log to
compile a report to management demonstrating
Sorry, should have mentioned that I tried that. The audit did nothing.
On Wed, May 12, 2010 at 2:03 AM, BEYERS Kurt wrote:
> Andrew,
>
> Perform the following action to see what is wrong with the volume:
>
> audit vol /tsmstg/001E.BFS fix=yes
>
> best regards,
> Kurt
>
> -Oorspronkelijk
While they are getting the advantage of the disk subsystem spreading the
lun over many drives, they are not getting an advantage at the OS level of
balanced I/O between the luns unless they are using some kind of OS level
stripping. I'm not really familiar with Linux . . . are they using LVM and
s
q content damaged=yes shows nothing also, just as q content showed nothing.
Is it possible, that since I had deduplication turned on, it turned
the files into chunks and it has way more chunks obviously than files,
and that's why it's taking so long? I never got any deduplication,
because the dat
Andy - This might be APAR IC67982. You are running TSM 6.1 with no
maintenance, and looks like it needs some.
Richard Sims
I am running TSM 6.2 . . . with no maintenance.
On Wed, May 12, 2010 at 8:50 AM, Richard Sims wrote:
> Andy - This might be APAR IC67982. You are running TSM 6.1 with no
> maintenance, and looks like it needs some.
>
> Richard Sims
>
--
Andy Carlson
--
Humm...that's interesting...I'll take a look ! Thanks Richard !
On Wed, May 12, 2010 at 8:18 AM, Richard Sims wrote:
> Leandro -
>
> The problem you're dealing with is a personnel management one, which can't
> be solved by technology alone. The management there is the only avenue of
> solution.
Intended for firewall security, the "sessioninitiation" property on the
nodes may work for this.
You will have to disable the setting if anyone actually wanted to do a
manual backup or restore
from the client side, but that's a quick "upd n"
Only the TSM Server would be allowed to start client ses
Have you tried to restore failed volume from copy pool?
Copy pools are without deduplication and damaged deduplicated data can be
recovered and thaen removed.
From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Andrew
Carlson [naclos...@gmai
I had the same problem and offsitereclaimlimit=20 (or whatever you want
to limit it to) worked for me.
In my particular situation my server is 5.4.1.0 (I know, very old!)
running on AIX 5.3 (5300-09-01-0847). I have a few (less than 5-10)
tapes at a 99% reclaimable level in my offsite COPYPOOL01
Greetings,
I have a customer running TSM 6.1.3.3 under RedHat Linux 5.2. The
Library Master instance on this server has a HP ESL722 tape library with
LTO4 tape drives, and a HP VTL emulating a ESL tape library with LTO3
drives. They are running the TSMscsi drivers to talk to the drives,
versi
I've tested this optionit works well, but in cases where the schedule
calls a script, didn't worked because the client could not start the
session...
On Wed, May 12, 2010 at 12:32 PM, Shawn Drew <
shawn.d...@americas.bnpparibas.com> wrote:
> Intended for firewall security, the "sessioninitiat
Did you upgrade the tape drivers?
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of John
D. Schneider
Sent: Wednesday, May 12, 2010 5:33 PM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] RedHat 5.2 to 5.4 upgrade causes problems for TSMscsi tape
driv
Len,
Thanks for your reply. No, we did not upgrade any of the TSM
software, including the tape drivers. We were running the
TIVsm-tsmscsi-6.1.3-1.x86_64 version both before and after the RedHat
5.2 to 5.4 upgrade.
I have since found out that there is a 6.1.3-3 version of the
driver. Sinc
Hello John,
I have not used tsm on Linux, but I have used ibm tape drives on linux. I used
the ibm lintape driver. These tape drives were fc based. I am not sure if your
tape drives are fc based. I am also not sure if the lintape driver supports
scsi tape drives.
I do have a tsm server runnin
Len,
The IBMTape drivers are intended only for the IBM tape drives. For
all others (such as the HP in my case), the TSM drivers are what TSM
wants us to use.
So I believe that we are using the right sort of driver, and it has
been working for some months; the problem only arose when w
18 matches
Mail list logo
