ADSM-L

[ADSM-L] SV: the purpose of "file" device class

2009-09-22 08:46:40
Subject: [ADSM-L] SV: the purpose of "file" device class
From: Christian Svensson <Christian.Svensson AT CRISTIE DOT SE>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 22 Sep 2009 14:46:20 +0200
Hi Rick,
What do you wanna know about VTL?
If you looking at Quantum or EMC (Who is OEM parts of Quantum VTL and 
FalconStor) is basically a Linux OS and running Quantums own Filesystem called 
NextFS or something like that, if I don't remember wrong.
NextFS is a great file system if you have large files such VTL or Media 
Streaming files.

The only reason why I should sale a customer a VTL is if they wanna run a 
LANFree backup to disk. 
But because you normally get better performance with a LTO-4 drive then disk, 
if you are streaming large files.
If they wanna run a backup of multiple small files over SAN then sure why not 
run a VTL.
Another reason that is good with VTL is to move over the CPU usage from the TSM 
Server to another hardware. So the TSM Server can focus on 
Backup/Restore/Reclamation/Migration and the stuff it is good on.

But to just buy a VTL because it is a VTL. No I don't see any point with it 
from a TSM perspective. I should instead invest on a Large Disk e.g IBM DSxx00 
System and use a fast index based filesystem such EXT4, TUX3 or BtrFS.
And spend time to create the FILE volumes so I don't get any fragmentation. 

Best Regards
Christian Svensson

Cell: +46-70-325 1577
E-mail: Christian.Svensson AT cristie DOT se
Skype: cristie.christian.svensson
________________________________________
Från: ADSM: Dist Stor Manager [ADSM-L AT VM.MARIST DOT EDU] f&#246;r Richard 
Rhodes [rrhodes AT FIRSTENERGYCORP DOT COM]
Skickat: den 22 september 2009 13:40
Till: ADSM-L AT VM.MARIST DOT EDU
Ämne: Re: the purpose of "file" device class

"ADSM: Dist Stor
> Hi TSM-ers!
> At this moment we are using a diskpool with a VTS-like (DL4106 by EMC)
> storage pool as nextpool.
> I too am looking at a FILE pool to replace this in the future, just to
> prevent a vendor lock-in for our TSM environment and of course the
> possibility to use de-dup.
> The only problem I see for using large FILE (100 Tb +) pools is the size
> of the filesystems on the host running the TSM server. Now it's AIX, but
> in the future we are likely to migrate to Linux.

It would be interesting to know if the VTL vendors (which are basically
implementing FILE type volumes inside the VTL) use a filesystem, raw
logical vlumes, raw disk . . . or whatever.

> Does anyone have experience with 100+ Tb FILE storagepools?
> Thanks for any reply in advance!

We keep looking at big pool of FILE devices vs VTL for our next
big purchase down the road - whether for the initial pool where
backups go directly, or are later migrated to.

We keep hitting our heads against a wall in trying to come up
with a way to make widespread use of a BIG FILE device pool:

- dedup: IBM has solved this one with v6.1!!!

- compression: To replace tape drive compression we need TSM server side
compression (or should I say FILE device pool compression).
We can't just push the job onto the clients.  VTL's
support hdwr compression via compression cards.  I wonder if IBM
will ever support server side hdwr compression via
add-on cards for FILE devices (http://www.aha.com).

- lanfree:  Provide good lanfree with FILE devices that is not
Sanergy.

We've got a couple years yet on our tape systms, but as of
today, we really don't see much way to effectively implement
a large scale FILE pool to replace our current TAPE drives.
FILE pools may be IBM strategic direction for TSM, but I think
they have a lot more work to make it a true reality.

Rick


-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.