Hi Eric,
If I where you should I start searching for much better Filesystem to run
FILECLASS on such EXT4, TUX or something similar.
And also split your FILECLASS to multiple LUNs. If a filesystem crash happened
you will get a minimal check disk time.
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ör Loon, EJ
van - SPLXM [Eric-van.Loon AT KLM DOT COM]
Skickat: den 22 september 2009 10:40
Till: ADSM-L AT VM.MARIST DOT EDU
Ämne: Re: the purpose of "file" device class
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.
What it the server crashes and you end up with one ore more corrupted
filesystems on you TSM server. How long will a filesystem check run on
such large filesystems?
Does anyone have experience with 100+ Tb FILE storagepools?
Thanks for any reply in advance!
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Kelly Lipp
Sent: maandag 21 september 2009 18:01
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: the purpose of "file" device class
During Oxford 2005, IBM stated that the File Device Class is the
strategic data structure. One can see this in action with the dedup
functionality in V6.
Our products use DISK for cachepool usually deployed on JBOD arranged
FAST disk (SAS or FC at 15K) as the initial target for client backups,
particularly for large numbers of clients with small data movement.
File Device class is used for large amounts of storage (since we can
have reclamation there). Our pools are targeted by clients moving a lot
of data daily, or are the target of migration from the cachepool.
I think both are still valid for the reasons already described but in
the long run DISK may go the way of the dinosaur.
Kelly Lipp
CTO
STORServer, Inc.
485-B Elkton Drive
Colorado Springs, CO 80907
719-266-8777 x7105
www.storserver.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
David McClelland
Sent: Monday, September 21, 2009 9:52 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] the purpose of "file" device class
Just to be uber-picky, FILE volumes now do allow multiple
sessions/processes
to read/write concurrently to a single FILE volume from TSM 5.5 onwards
(http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/topic/com.ibm.it
smms
munn.doc/anrsgd5515.htm#wq28).
The big picture as I've read it is that IBM are perhaps angling the
user-base towards using FILE volumes, and that new developments would be
implemented against FILE technology rather than DISK. That being said,
it's
fair to say that many people are simply more comfortable with the ease,
simplicity and habit of implementing and managing DISK volumes.
/DMc
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Shawn Drew
Sent: 21 September 2009 15:58
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] the purpose of "file" device class
Disk Based (Random access) lets you have several sessions all sending
data
to it. This removes the need to queue backups like all the competitors.
But it will fragment as data expires and there is no defrag for random
access.
File devices (Sequential access) do also fragment over time, just like
tape, but you are able to run reclamation on them. But sequential
access
would cause queuing.
They each have different pro's and con's which make them suited for
different tasks. (long term vs short term storage)
Regards,
Shawn
________________________________________________
Shawn Drew
This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in
error,
please delete it and immediately notify the sender. Any use not in
accord
with its purpose, any dissemination or disclosure, either whole or
partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall
(will)
not therefore be liable for the message if modified. Please note that
certain
functions and services for BNP Paribas may be performed by BNP Paribas
RCC,
Inc.
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.109/2384 - Release Date:
09/20/09
06:22:00
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message.
Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
**********************************************************************
|
