Raw devices just get added to the storagepool, no need to format them.
As was noted in another thread earlier, the diskpool type will need to
be "DISK".
I'm not sure why you would want to create 16GB volumes at the OS level.
I used 16GB volumes because that was the size of one of my JBOD. I have
other TSM servers that have 9GB or 36GB volumes. It all depends on the
size of the disks I am using. In your case, you should create the AIX
Logical volumes the same size as the LUNs that the OS sees. A one-to-one
relationship: 1 LUN= 1 AIX LV.
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Joni Moyer
Sent: Friday, August 19, 2005 12:39 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: AW: [ADSM-L] Migration Speed Has Plummeted
Thanks for the suggestions Ben!
I did take the 10 LUNS and put them into 1 logical volume/filesystem on
the AIX server and called it /tsmprod/stgpool2. I then formatted
multiple TSM volumes that were either 16GB or 32GB of the type=DISK and
put them in a storage pool. I've already removed all of the SATA disk
from the TSM server, so half of the job is done. So I guess what is
left is to create 16GB raw logical volumes on the AIX server and then
define them to TSM with a type of DISK? Do I have to allocate them and
format them? I was previously doing a define volume oracle xxxxxx
access=readw format=16384.
Would I do the same with the raw disk volumes?
Thanks again!
********************************
Joni Moyer
Highmark
Storage Systems
Work:(717)302-6603
Fax:(717)302-5974
[EMAIL PROTECTED]
********************************
"Ben Bullock"
<[EMAIL PROTECTED]
COM>
To
Sent by: "ADSM: ADSM-L@VM.MARIST.EDU
Dist Stor
cc
Manager"
<[EMAIL PROTECTED]
Subject
.EDU> Re: AW: [ADSM-L] Migration Speed
Has Plummeted
08/19/2005 11:56
AM
Please respond to
"ADSM: Dist Stor
Manager"
<[EMAIL PROTECTED]
.EDU>
Hmm, my suggestions were made assuming she would put the
raw devices into a typical storage pool of a "DISK" type.
I saw the discussion about the serial/random disk usage and
the SATA, and how it could be the reason for her performance problem,
and I was buying that reasoning until she showed us how she had created
her volume.
I ~believe~ she is taking 10+ LUNs, combining them into 1
logical volume, creating a filesystem on the volume, likely doing a
'dsmfmt' and then putting it into a storagepool with a type of "DISK".
(one of her screen shots definitely showed the storagepool was "DISK")
Once I saw that, I could see why her performance was poor,
every concurrent session migrating from that diskpool will access that
one volume at the same time, causing all the LUNS underneath to be busy
at the same time, causing a lot of head contention.(as per my earlier
email about TSM's round-robin access of volumes in a Storagepool).
Seeing that configuration, I think that the underlying SATA disks are
the root problem, but her aggregating them into 1 huge volume is the
reason.
I believe she will see somewhat better performance if she
migrates all the data off her current 1TB storagepool volume, removes
the volume from the storagepool, unmount the filesystem, removes the
filesystem and the underlying LV, creates volumes with a 1-to-1
LV-to-LUN relation and the defines all those raw LVs into the
storagepool.
The pain would be getting all the data migrated off that
one volume, but once all the data is migrated off the vol, it's not a
lot of work a the AIX level to take the vol apart and put it back
together. I would suggest she try this before changing the filesystem to
a type of "FILE" and then encountering the additional "gotchas" that I
have read in this listserv having to do with reclamations and
aggregates.
My 2-cents,
Take it with a grain of salt, preferably while it is on the edge of a
Margarita glass. ;-) Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Stapleton, Mark
Sent: Thursday, August 18, 2005 9:45 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: AW: [ADSM-L] Migration Speed Has Plummeted
FYI, per the TSM manual, raw filesystems should *not* be used in a
file-based disk pool. At this time, file-based disk pools are the way to
go with SATA disks (performance-wise).
--
Mark Stapleton ([EMAIL PROTECTED])
IBM Certified Advanced Deployment Professional
Tivoli Storage Management Solutions 2005 IBM Certified Advanced
Technical Expert (CATE) AIX Office 262.521.5627
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf
>Of Leigh Reed
>Sent: Wednesday, August 17, 2005 5:16 PM
>To: ADSM-L@VM.MARIST.EDU
>Subject: Re: AW: [ADSM-L] Migration Speed Has Plummeted
>
>Joni,
>
>If you read Ben Bullock's recent posting, I agree with everything he
>has said. I would definitely use raw disk volumes (in a Unix world).
>
>
>Leigh
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf
>Of Joni Moyer
>Sent: 17 August 2005 20:31
>To: ADSM-L@VM.MARIST.EDU
>Subject: Re: [ADSM-L] AW: [ADSM-L] Migration Speed Has Plummeted
>
>Hi Leigh,
>
>I have just added EMC fibre channel disk from a CX700 in the following
>pieces of physical disk under the filesystem /tsmdev/stgpool1
>
>CHRS044 /tsmdev/stgpool1
>
>lun 175 100 GB
>lun 178 100 GB
>lun 181 100 GB
>lun 184 100 GB
>lun 187 100 GB
>lun 190 100 GB
>lun 193 100 GB
>lun 199 100 GB
>lun 204 100 GB
>lun 210 100 GB
>
>Total 1000 GB
>
>When you stated using many small TSM disk storage pool volumes, would
>anyone happen to know what a good, acceptable size TSM volume would be?
>Thanks!
>
>********************************
>Joni Moyer
>Highmark
>Storage Systems
>Work:(717)302-6603
>Fax:(717)302-5974
>[EMAIL PROTECTED]
>********************************
>
>
>
> "Leigh Reed"
> <[EMAIL PROTECTED]
> >
>To
> Sent by: "ADSM: ADSM-L@VM.MARIST.EDU
> Dist Stor
>cc
> Manager"
> <[EMAIL PROTECTED]
>Subject
> .EDU> Re: AW: [ADSM-L] Migration Speed
> Has Plummeted
>
> 08/17/2005 10:39
> AM
>
>
> Please respond to
> "ADSM: Dist Stor
> Manager"
> <[EMAIL PROTECTED]
> .EDU>
>
>
>
>
>
>
>Joni
>
>The following URL is to the TSM V5.3 Technical Guide Redbook.
>
>If you go to section 3.4.6, it discusses some changes in TSM 5.3 that
>lend themselves to 'disk only backups'
>Obviously, if you're not at 5.3 yet, then they may not be of use to
>you.
>
>I personally would consider SATA disk as a possible replacement to
>sequential tape, but I would still use good quality fast disk as
>traditional 'random' disk pool to stage the nightly backups. I think
>that it is widely recognised that significantly 'slicing up' the
>diskpool into a large number of smallish volumes, greatly improves
>performance (certainly on the backup). I believe that this is because
>of the 'multi-threaded' nature of TSM.
>
>I would imagine that the config for the best performance of SATA disk
>as random TSM backuppool, would be to configure each SATA disk as a
>single TSM volume within the backuppool and ensure that you have enough
>SATA disks/backuppool volumes as you have sessions in at the same time.
>
>However, with SATA disk capacity increasing rapidly, it's not efficient
>to have a 100 x 250GB SATA disks (100 TSM volumes) sitting in your
>backuppool, that only ever get 10% utilised.
>
>I must state that this is just my opinion, I have no direct experience
>with SATA disks.
>
>Leigh
>
