Very large disks on VMS
Jim Geier
moreso than its predecessors, it is possible to have VERY large disks on
a VMs system. Are there any problems or issues regarding how well VMS
will handle disks that are 300, 400, 500 GB or even larger? For example,
how does VMS handle things like the free block list or cache tables?
Will these things get unmanageable with extremely large disks?
--jim geier--
Rob Young
Recent bitmap work in 7.2+ (check me for all details, I'm not
grinding it out looking for refs - top of head stuff) you
can get cluster size of 1 for disks up to 133 GByte (maybe 136?).
With cluster factor calcs (back in the day) we would have to determine
min cluster factor for disk size if we wanted to do something
other than defaults (and you can trudge through google for
the formula).
Today with 7.2+ and cluster size of 3, perhaps you can do a 300 GByte
drive.
But even if you can do it, I'm not sure about the wisdom as when
you calculate restores, you can see you could be done a very long
time doing a restore on a blown out raidset/disk.
Rob
JF Mezei
>
> With the evolution towards larger and larger disks, and now with the EVA
> moreso than its predecessors, it is possible to have VERY large disks on
> a VMs system.
Back in the 1980s, VMS supported HUGE drives. They were so big, they needed 2
males to lift, required a 1/3hp electric motor to spin, 15 ams circuit to
power EACH drive. Each drive assembly had at least 4 fans.
Is that big enough for you ?
Alan Frisbie
>
> Jim Geier wrote:
> >
> > With the evolution towards larger and larger disks, and now with the EVA
> > moreso than its predecessors, it is possible to have VERY large disks on
> > a VMs system.
>
> Back in the 1980s, VMS supported HUGE drives. They were so big, they needed 2
> males to lift, required a 1/3hp electric motor to spin, 15 ams circuit to
> power EACH drive.
I would like to see an RP06 lifted by only two people, male or female.
Heck, I know some people who had trouble just lifting the pack!
Alan
Bill Todd
"Jim Geier" <jimg...@jimgeier.com> wrote in message
news:000301c2cbb0$caebaa40$6b3e11ac@jcgt23...
My impression is that there may still be 32-bit fields in the file system
(and possibly disk driver) internals that limit supported disk size to
(probably) 2 TB (2^32 512-byte blocks). Have you checked the FAQ (if it's
not there, then perhaps Fred or Hoff will jump in with an answer)?
- bill
Hoff Hoffman
In article <mJ6dnc72H8u...@metrocast.net>, "Bill Todd" <bill...@metrocast.net> writes:
:
:"Jim Geier" <jimg...@jimgeier.com> wrote in message
Detailed information on this particular storage topic is included in
the OpenVMS Frequently Asked Questions (FAQ).
Additionally, information related to the directory cache processing is
included in the FAQ.
The FAQ is available in various file formats and at various websites,
including the following (alias) URLs:
http://www.hp.com/products/openvms/
http://www.openvms.compaq.com/
Please download and keep a current (text-format) edition of the OpenVMS
FAQ handy, and (most importantly) please remember to read and to search
through the FAQ.
After you've downloaded and read through the relevent sections of the
OpenVMS FAQ, any additional questions you might have can be addressed
here.
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.openvms.compaq.com
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com
David J. Dachtera
Heartbreak Deja Vu:
Ever drop an RP06 pack?
Ever see a FE drop an RP06 calibration (reference) pack?
Drop a line to Mark Levy for these and other interesting RP06 stories
(including trashing a WHOLE drive's worth of heads - and they weren't
even installed at the time!).
--
David J. Dachtera
dba DJE Systems
http://www.djesys.com/
Unofficial Affordable OpenVMS Home Page:
http://www.djesys.com/vms/soho/
Jim Brankin
The file system records free blocks as a bitmap in [00000]BITMAP.SYS. This
is cached and the cache size is defined by the ACP_MAPCACHE sysgen parameter.
If BITMAP.SYS becomes very big then it seems reasonable to increase the size
of the cache. The cache should be able to hold ALL of the biggest bitmap.sys
on your system and a bit more besides, IMHO. That way when a disk is almost
full and the file system is scratching around looking for the last few blocks
it will have the bitmap in memory.
Since the change which allows smaller cluster sizes I have increased the
ACP_EXTCACHE parameter to 2000. I don't have any scientific reason for doing
this but it seems to me that if there are more clusters on the disk it is
likely there will be more extents and therefore a bigger cache seems like a
good idea. Increasing the size of the extent cache makes some disks less
prone to fragmentation and some more so. I cannot figure out what is going
on there.
- Jim
Fred Kleinsorge
system to overcome the size and performance limitations of ODS2/5. When the
current stuff was designed, the RP06 was cuting edge.
"Bill Todd" <bill...@metrocast.net> wrote in message
news:mJ6dnc72H8u...@metrocast.net...
Paul Repacholi
> We are currently limited to 32-bit LBN's. We are evaluating a new
> file system to overcome the size and performance limitations of
> ODS2/5. When the current stuff was designed, the RP06 was cuting
> edge.
Fred, I think you will find that RP03s and RP04s where cutting edge,
and Merlin, RP06s, was a gleem in the eye. ODS-2 is possibly the
oldest part of VMS. Mind, it has changed a fair bit over the years.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
Larry Kilgallen
> "Fred Kleinsorge" <kleinsorge@star-dot-zko-dot-dec-dot-com> writes:
>
>> We are currently limited to 32-bit LBN's. We are evaluating a new
>> file system to overcome the size and performance limitations of
>> ODS2/5. When the current stuff was designed, the RP06 was cuting
>> edge.
>
> Fred, I think you will find that RP03s and RP04s where cutting edge,
> and Merlin, RP06s, was a gleem in the eye. ODS-2 is possibly the
> oldest part of VMS. Mind, it has changed a fair bit over the years.
Hardware that is cutting edge for customers is often passe for VMS
Development :-). The January EV7/Marvel announcement date seems
to have shifted a couple of times within that month from the rumored
date. I am quite certain it was not that VMS Development was waiting
for their first EV7 system.