Hi Eric,
Exactly - tapes seek to the closest file mark. I've heard the same thing
about vtl's - they
do this very fast. The obvious explanation is that the vendor indexes the
file marks and
opens the virtual tape directly to that point.
The question is whether file type volumes do something like this also?
Can TSM open
directly to a desired file on a file type volume?
We don't have a VTL, but we are talking a lot about it - pro/con. I can
see us moving to
at least primary pools on VTL the next time we need to upgrade our tape
drives/libraries.
Here are some of the things we've been discussing . . . . .
1) Do we really want a tsm server with +100tb of filesystems (what was
mentioned
in this thread!!! ). It's interesting that IBM could not provide a
reference for this. I know
in tsm v5.3 the file volumes can be in multiple filesystems. When we get
onto v5.3
(upgrade is in testing phase) I'm going to look at this feature some more.
Now, the
VTL itself is a computer with a filesystem - doesn't it have the same
problem? If the
VTL appliance/head crashes would it not have to possibly fsck +100tb? I
may not
want to manage this directly on AIX, but the VTL has the same issue.
2) If we use file devices we have to turn on client complression on all
servers. Currently,
we don't use client compression on most hosts, and get about a 1.5-to-1
ratio from the
tape drives. We're not sure many/most of our Windows and Netware servers
have the
power to perform client compression.
3) VTL's seem to have very fast seek times (as we've been discussion). I
don't know,
and haven't been able to find out if file volumes have this same fast seek
times.
4) At the recent EMC technical conference at a presentation about their
CDL, they
recommended that colocation be TURNED OFF. They said that the speed of the
mounts and seeks made colocation unnecessary. I would assume this also
with
file devices, but it again depends upon the speed of seeking to a file in a
file type volume.
5) We just met with our local IBM TSM expert (very good guy!) about some
things with
our environment, and this topic came up. Interestingly, he even
recommended possibly
using disk type devices for backup-to-disk. This was a big surprise! I
thought it was
mostly agreed that only file type devices should be used.
6) When you think about it, a VTL is really being used as a filesystem
that provides
management of tsm volumes (the filesystem itself), fast access to tsm
volumes
(mounts), fast access to files in those volumes (seeks), and compression
of those volumes. If I can do all this with file type volumes, then I
think it would
be less expensive to just purchase a lot of ATA disk.
I'm glad our decision related to a VTL are at least a year out.
Rck
"Loon, E.J. van -
SPLXM" To: ADSM-L AT VM.MARIST
DOT EDU
<Eric-van.Loon@KL cc:
M.COM> Subject: Re: File dev. type vs.
VTL
Sent by: "ADSM:
Dist Stor
Manager"
<[email protected]
.EDU>
06/20/2005 08:35
AM
Please respond to
"ADSM: Dist Stor
Manager"
Hi Richard!
Tapes aren't read from the beginning either, so why should TSM do so for
file volumes? A tape is wound to the closest data marker and from that
point, the read starts.
Although a VTS simulates tapes, the read mechanism seems to be much faster.
We are currently starting with testing a EMC DL700 disk library. From other
users I heard that the combined volume mount and position to data (seek)
times are always less than a second, no matter where the data is located on
the virtual volume.
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines
-----Original Message-----
From: Richard Rhodes [mailto:rrhodes AT FIRSTENERGYCORP DOT COM]
Sent: Monday, June 20, 2005 13:47
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: File dev. type vs. VTL
One of the things I've wondered about VTL's and file devices is how they
handle seeks.
What happens when TSM needs to access a file that's at the end of a vtl
"tape" or file volume?
For a file device, does TSM open the file and read the entire volume till
it gets to the
file or is tsm smart enough to seek closer to the file. If it has to read
the entire volume then this is an
argument for smaller file volumes.
For a vtl - same basic question. Since a vtl emulates tape drives, I
assume tape marks
have to be recorded. I wonder if a vtl indexes the tape marks so it can
seek directly to a mark
on disk.
Rick
"Loon, E.J. van -
SPLXM" To:
ADSM-L AT VM.MARIST DOT EDU
<Eric-van.Loon@KL cc:
M.COM> Subject: Re: File dev. type
vs. VTL
Sent by: "ADSM:
Dist Stor
Manager"
<[email protected]
.EDU>
06/20/2005 06:56
AM
Please respond to
"ADSM: Dist Stor
Manager"
Hi Dough!
We choose a VTL over a file device class because several reasons:
1) IBM couldn't provide us a reference site with a 100 TB. + file device
class.
2) We were not sure how AIX would handle a crash with several very large
filespaces. How long will a filesystem check last?
3) How long will it take for TSM to mount a few hundred file volumes during
startup?
If you decide to use a file device class, limit the size of your volumes
and
pre-define them. The smaller the volumes are, the less volume contention
you
will encounter during multiple (multi-session) restores. You should
pre-define them to prevent fragmentation on the disks.
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines
-----Original Message-----
From: Thorneycroft, Doug [mailto:dthorneycroft AT LACSD DOT ORG]
Sent: Friday, June 17, 2005 19:47
To: ADSM-L AT VM.MARIST DOT EDU
Subject: File dev. type vs. VTL
I'm getting ready to add more disk to my TSM server,
Are there any advatage/disadvatages to using a Virtual tape library
instead of TSM defined file device types.
(Do TSM file device types work with multi session restores?)
Doug Thorneycroft
> Systems Analyst
> County Sanitation Districts of Los Angeles County
> 1955 Workman Mill Road
> Whittier, CA 90601
> Tel: (562)699-7411, Ext. 1058
> Fax:(562)695-6756
> www.lacsd.org
>
>
**********************************************************************
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.
**********************************************************************
-----------------------------------------
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.
|
