Stefan, Thank you for the reply. You said *"but for backup data on disk I think nothing beats it, maybe even in any product I've ever used."*
Unfortunately, due to the overhead/requirements/demands (as other replies have pointed out) we can NOT use it for client/node backups since none of our current production ISP servers have the CPU/storage (most are 32-thread and NFS/ISILON storage) What we wanted to use it for was on our offsite replication TARGET server (which has 64-threads and 256GB RAM), which is used primarily for replication of data from our onsite ISP servers as well as offsite database backups for the onsite ISP servers (devclass server). When we tested/created a small directory/container area on internal disk on this server, any management class we pointed to it was rejected and the incoming replicas/DB backups were redirected to the NEXTSTGPOOL which was a normal, devclass FILE storagepool. Perhaps next year when we replace one of our local ISP servers with a much bigger/beefier (72-threads and 120TB internal disk storage). On Wed, Sep 26, 2018 at 6:17 AM Stefan Folkerts <stefan.folke...@gmail.com> wrote: > Zoltan, > > I'm not sure I understand your issues, we use directory containerpools for > all but a few of our Spectrum Protect customers and it's miles ahead of > what the fileclass-based storagepool bring in terms of performance, > Spectrum Protect database impact (size wise). Yes, it isn't capable of > certain, until then standard Spectrum Protect storagepool functions but for > backup data on disk I think nothing beats it, maybe even in any product > I've ever used. > > Of course you can't write Spectrum Protect database backups to it, it > doesn't even have a device class and it's most certainly not sequential in > any way but normal database backups are very much able to land in the > directory containerpool and you will enjoy enormous deduplication and > compression benefits, much higher net savings then when using the filepool > at any customer site I've implemented it. > > So, could you please explain what you are trying to do that doesn't work? > > Regards, > Stefan > > > On Mon, Sep 24, 2018 at 3:49 PM Zoltan Forray <zfor...@vcu.edu> wrote: > > > Thanks for all the comments/suggestions and a somewhat consensus to avoid > > directory/containers. > > > > We decided to at least get our "feet wet" and play with > > directory/containers on our offsite replica-target server (which has the > > horsepower) only to realize everything we tried to use it for was > > not-allowed (DB backups from production servers and replication target > > storage pools) and everything we directed to it was redirected to the > "next > > stgpool"? > > > > So we are confused - what can you use directory/containers for at the > > 7.1.7.400 server level? Only real client backups? > > > > > > > > On Tue, Sep 18, 2018 at 11:40 AM PAC Brion Arnaud < > > arnaud.br...@panalpina.com> wrote: > > > > > Zoltan, > > > > > > If I understood well, your storage is Isilon based : in this case do > not > > > even think of using CONTAINER pools, as performance will be horrible. > > > Not much time to talk about this, but to make a very long story short, > we > > > are about to dump/trash /resell the brand new Isilon arrays we bought > 8 > > > months ago, and to replace them with direct attached storage > (Storwize), > > as > > > we never reached sufficient performance levels. Cases have been opened > > with > > > IBM and EMC as well, to no result at all, beside a suspected block size > > > issue which would refrain the Isilons to work at expected speed. > > > If you plan to go for such a hardware configuration, my only advice is > : > > > run away, as fast as you can ! > > > > > > Cheers. > > > > > > Arnaud > > > > > > -----Original Message----- > > > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of > > > Zoltan Forray > > > Sent: Tuesday, September 18, 2018 3:37 PM > > > To: ADSM-L@VM.MARIST.EDU > > > Subject: CONTAINER pool experiences > > > > > > We are investigating using CONTAINER pools for our offsite replica > server > > > vs the current FILE method which is killing us with the constant dedup, > > > reclaims, etc. > > > > > > So, what are the "gotchas' ? We are still at V7.1.7.400 so I figure > we > > > will have to do without any new features added in the V8 branch. But is > > it > > > problematic enough at V7 to avoid it? > > > > > > Your thoughts? Experiences? > > > > > > -- > > > *Zoltan Forray* > > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > > > Xymon Monitor Administrator > > > VMware Administrator > > > Virginia Commonwealth University > > > UCC/Office of Technology Services > > > www.ucc.vcu.edu > > > zfor...@vcu.edu - 804-828-4807 > > > Don't be a phishing victim - VCU and other reputable organizations will > > > never use email to request that you reply with your password, social > > > security number or confidential personal information. For more details > > > visit http://phishing.vcu.edu/ > > > > > > > > > -- > > *Zoltan Forray* > > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator > > Xymon Monitor Administrator > > VMware Administrator > > Virginia Commonwealth University > > UCC/Office of Technology Services > > www.ucc.vcu.edu > > zfor...@vcu.edu - 804-828-4807 > > Don't be a phishing victim - VCU and other reputable organizations will > > never use email to request that you reply with your password, social > > security number or confidential personal information. For more details > > visit http://phishing.vcu.edu/ > > > -- *Zoltan Forray* Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator Xymon Monitor Administrator VMware Administrator Virginia Commonwealth University UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://phishing.vcu.edu/
