This is correct, unless you specify *DEDUPEREQUIRESBACKUP NO** in the
dsmserv.opt file.*
On Tue, Nov 1, 2011 at 1:21 PM, Ehresman,David E.
deehr...@louisville.eduwrote:
I believe a deduped primary storage pool has to be backed up to a copy
pool before the reclaim process will discard the
I had an odd situation occur involving formatting disk storage volumes on
a Linux server.
In the past, when creating and formatting storage pool volumes, a 300GB
volume would normally take an hour or more. I could watch the space being
allocated, piece-by-piece until it reached 300GB and then
On 11/02/2011 08:49 AM, Zoltan Forray/AC/VCU wrote:
I had an odd situation occur involving formatting disk storage volumes on
a Linux server. [...]
So, what gives?
Is there some dramatic change in 6.2.3.0 (this is my first server
upgraded to this level) effecting the behavior of creating
Yes, this was finally fixed for the UNIX platforms in 6.2.3.
This update was released just in time for me when I had to format 40
TB of disk/file on a new server. Would have taken a week otherwise.
I guess it does the same as on the windows platform so no need to
write zeros on all blocks on
Thanks for the confirmation. I too am getting ready to format 20TB+ on
2-other servers so I guess I will have to update the servers to 6.2.3.0
first (or jump straight to 6.3)
I wonder if this will effect FILE devclasses/processing? I have tried to
use FILE devclasses numerous times and always
Speaking of 6.2.3, I just noticed a 6.2.3.100 patch but none of the links
in the README.htm file work. Anyone have the list of what is fixed for
this patch?
Zoltan Forray
TSM Software Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu -
Bummer, I just formatted 30TB of disk spool on v6.2.2.2 and it took days...
--
-- Skylar Thompson (skyl...@u.washington.edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine
On 11/ 2/11 06:47 AM, Hans
Hi,
I've just upgraded a V6.2.2.2 TIVsmSdev pkg on Solaris x86_64 to
v6.2.3.0 and the DataDomain virtual library stopped working !
After downgrading back to v6.2.2.2, it starts working again with no
single error whatsoever.
The errors I get (in hundreds) with TIVsmSdev v6.2.3.0, after starting
Hi all,
I guess that IBM started using the posix fs call to allocate storage. The
command finishes in seconds, but at least on AIX the actual I/O still lasts
forever. Some operating systems might be able to allocate disk space a lot
quicker. It all boils down to the particular unix flavor
Anyone here started playing with this TDP? We can't get it to install.
Most folks here use a terminal window and the -i console option has
always worked in the past. With 6.3 it tried to kick in a GUI/Java
session and thus fails since it can't start an X-Windows session
I've been digging through the compatibility matrices at e.g.
http://www-01.ibm.com/support/docview.wss?rs=663context=SSGSG7uid=swg21053218loc=en_UScs=utf-8lang=en
which I'll parenthetically note were reasonably straightforward to find,
and reasonably simple to parse. Nice.
But I didn't see a
Your DataDomain VTL has more than 4400 slots in it. If you can, reduce it to
4400 slots, and it will resume normal behavior. You'll need to delete and
recreate the library for this to take effect, but it will work.
I've got a PMR open with IBM and a Case open with DataDomain on this issue. I
Such problems do not exist when you use an externally managed library. With an
External Library Manager TSM is not aware of the slot count of a library, thus
removing any dependence on TSM having pre-existing knowledge of library model
architecture. This approach also allows for infinite
To make things very clear, there is no relevant design limitation in TSM, this
is is just a bug. Of course Gresham software is just as vulnerable to human
error. These things happen to the best of us. Don't believe the FUD that
commercial software vendors spread.
On 2 nov. 2011, at 23:52,
We have the same issue. In our case, it's caused by a corrupt or
mismatched dscenu.txt file, causing ANS0106E message index not found for
message... in dsmerror.log.
To fix it, we stop the TSM scheduler (no need for that if you're using CAD
I guess), replace the dscenu.txt file with a good one
Andy, the whole point of VSS is to freeze the activity and get a consistent
SystemState backup.
Right?
So, if this HPOVO issue is going on, then certain files can't get
enumerated to VSS.
OK. Then the safety-net feature backs them up to the drive instead of to
some VSS writer.
But aren't they
16 matches
Mail list logo
