Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[ADSM\-L\]\s+Determining\s+devclass\s+FILE\s+values\s+\(a\.k\.a\.\s+New\s+Server\s+\-\s+Part\s+Deux\)\s*$/: 15 ]

Total 15 documents matching your query.

1. [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Date: Fri, 17 Sep 2010 10:32:09 -0400
the responses leaned to 6.2.x. With that decision made, the next is laying out the structure of storage pools and such. Most discussions/directions from here/IBM say that DEVCLASS FILE is the way to
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00173.html (13,281 bytes)

2. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Grigori Solonovitch <Grigori.Solonovitch AT AHLIUNITED DOT COM>
Date: Fri, 17 Sep 2010 22:49:15 +0300
I have migrated most of primary pools to devc/stgpool FILE and found them perfect (it was done as a preparation to use de-duplication in 6.x, by the way am still 5.5.4). It is good from any point of
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00179.html (14,889 bytes)

3. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Johnny Lea <jlea AT UMC DOT EDU>
Date: Tue, 21 Sep 2010 10:30:07 -0500
I am using file class on datadomain albeit 5.5.3. Initially I set the maxcap at 25GB. This seemed to work OK except my reclamation is getting out of hand. For example a 200GB file stored across sever
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00216.html (16,168 bytes)

4. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Date: Tue, 21 Sep 2010 13:04:27 -0400
So, what did you increase the size to? Just in case I don't completely understand the pros/cons of FILE vs DISK, I plan to use this 5.3TB SAN disk space the same way I am using DISK on my other serve
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00217.html (17,190 bytes)

5. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Johnny Lea <jlea AT UMC DOT EDU>
Date: Tue, 21 Sep 2010 14:48:49 -0500
I increased my windows server devclass volume size to 50GB and database devclass to 200GB. If reclamation is not involved then I don't know if it really matters as to volume size. --Original Message-
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00219.html (18,305 bytes)

6. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Grigori Solonovitch <Grigori.Solonovitch AT AHLIUNITED DOT COM>
Date: Wed, 22 Sep 2010 07:56:25 +0300
There is a VERY BIG difference between DISK and FILE. DISK device class has RANDOM access and reclamation is not required at all. FILE device class has SEQUENTIAL access. File system is used to keep
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00221.html (15,803 bytes)

7. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Grigori Solonovitch <Grigori.Solonovitch AT AHLIUNITED DOT COM>
Date: Wed, 22 Sep 2010 09:34:22 +0300
I forget to mention this in my previous message, but I have selected volume size 64GB because of file size as well. TDP for Oracle and Mail (Exchange) produces quite big files. In my case they are st
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00222.html (19,364 bytes)

8. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Stef Coene <stef.coene AT DOCUM DOT ORG>
Date: Wed, 22 Sep 2010 11:29:29 +0200
Also, do you have a (fast) DISK based volume in front of the FILE storage pool? We do this so we can allow lots of client backups coming in and use the number of migration processes to control the da
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00223.html (15,124 bytes)

9. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Grigori Solonovitch <Grigori.Solonovitch AT AHLIUNITED DOT COM>
Date: Wed, 22 Sep 2010 13:39:29 +0300
Yes, I had DISK pools before, but I have migrated all of them to FILE to be able to use TSM Server de-duplication. In my opinion, everybody can use DISK storage pool as less painful till you do not
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00224.html (17,647 bytes)

10. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Stefan Folkerts <stefan.folkerts AT ITAA DOT NL>
Date: Wed, 22 Sep 2010 13:17:42 +0200
De performance of a disk based storagepool will be fine at the start but will degrade over time due to fragmentation, I have seen this happen on large permanent use diskpools. I would advise only usi
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00225.html (18,399 bytes)

11. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Richard Sims <rbs AT BU DOT EDU>
Date: Wed, 22 Sep 2010 07:42:01 -0400
I think this is particularly an issue with TSM volumes implemented within file systems, where disk block locations are "pot luck". (Formatting multiple disk pool volumes in parallel, explicitly via d
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00226.html (13,979 bytes)

12. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Johnny Lea <jlea AT UMC DOT EDU>
Date: Wed, 22 Sep 2010 08:53:19 -0500
much better. There was less reclamation needed because it is less likely that a volume has a status Filling. Interesting concept Stef...just the opposite of what I did to fix the problem. I'll give t
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00229.html (13,571 bytes)

13. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Stef Coene <stef.coene AT DOCUM DOT ORG>
Date: Wed, 22 Sep 2010 17:28:25 +0200
This is an AIX server with a 7 TB jfs2 filesystem with 1381 files in it. For now, no downside found. Why have you changed to bigger FILE volumes? And do you use a DISK based storage pool as 'buffer'?
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00233.html (13,564 bytes)

14. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Johnny Lea <jlea AT UMC DOT EDU>
Date: Wed, 22 Sep 2010 10:49:51 -0500
My idea was to create volumes large enough to hold all or large portions of entire files of this size. I haven't been doing this long enough for mass expirations to take effect yet so I don't know fo
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00234.html (14,463 bytes)

15. Re: [ADSM-L] Determining devclass FILE values (a.k.a. New Server - Part Deux) (score: 1)
Author: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Date: Wed, 22 Sep 2010 11:52:56 -0400
Very interesting discussions about FILE devclass and configuration whoas......lots of guess-work and differing opinions. Sounds like FILE adds another level of administrations (reclaims?) and not sur
/usr/local/webapp/mharc-adsm.org/html/ADSM-L/2010-09/msg00235.html (17,196 bytes)


This search system is powered by Namazu