Funny you should mention that...
While setting up our new TSM server on HP-UX, I opted to define all of the
disk pools as sequential files. I defined a Device Class of type FILE
(called... FILE !) with capacity of 6G. Then I defined several Storage
Pools using DEVCLASS FILE. On my older server, the Storage Pools use
DEVCLASS DISK.
My reason for trying this approach was that on the old server, we would get
into situations (usually on weekends) where we would run out of scratch
tapes, and the disk pools would fill up. Since there were no tapes to
migrate to, backups would cancel. In order to get them rolling again, I
would delete disk volumes from other disk pools that were not being used,
rm the files from the directory, then define new volumes to the full disk
pools.
By using the DEVCLASS FILE approach, the use of disk space is dynamic and
self-regulating. Disk volumes get allocated (in 6G increments) when and
where needed. No need to remove and define volumes.
I can't really compare performance between the two servers because the
hardware on the new server is much faster (HP 2100 disk array vs. internal
F50 non-SSA disks). However, I have seen some strange behaviour... one
system backup in particular, got a "server out of storage" message, even
though there was disk AND scratch tapes available... My thought is that
because it was a collocated pool, and the client had a high
resourceutilization (8 I think), it got into a "waiting for access"
condition. I had to change that management class to go direct to tape and
reduce the resourceutilization to 1 to get it to complete! There seems to
be some incompatibility when using collocation and resourceutilization > 1
together.
Other than that one incident, it's been working pretty well.
Robin Sharpe
Berlex Laboratories
Kelly Lipp
<lipp@STORSOL
.COM> To: [EMAIL PROTECTED]
cc: (bcc: Robin Sharpe/WA/USR/SHG)
10/24/01 Subject:
11:26 AM Re: SAN Environment
Please
respond to
lipp
And when you do go directly to disk, it is not into a diskpool but rather
into a pool defined with a device class of type file. The end result is
more or less the same but the configuration is quite different.
This should bring up an interesting discussion about what is more
efficient:
a traditional diskpool of devclass DISK and a "diskpool" using the file
device class. Apparently, and I have no experience to back this up, the
second type of disk pool is faster due to its sequential nature. Won't
that
change our thinking?
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs, CO 80949
[EMAIL PROTECTED] or [EMAIL PROTECTED]
www.storsol.com or www.storserver.com
(719)531-5926
Fax: (240)539-7175
