Return-path: <alpha-osf-managers-relay_at_sws1.ctd.ornl.gov>
Received: from sws1.CTD.ORNL.GOV by SLUVCA.SLU.EDU (PMDF V5.0-4 #5070)
id <01HVTZI897Z48Y56IA_at_SLUVCA.SLU.EDU> for ALPHAOSF_at_SLUAVA.SLU.EDU; Fri,
29 Sep 1995 03:25:43 -0600 (CST)
Received: (from daemon_at_localhost) by sws1.CTD.ORNL.GOV (8.6.10/8.6.10)
id LAA06311 for aomaa; Mon, 25 Sep 1995 11:39:08 -0400
Received: from oaunx1.ctd.ornl.GOV (oaunx1.ctd.ornl.gov [128.219.128.17])
by sws1.CTD.ORNL.GOV (8.6.10/8.6.10) with ESMTP id LAA06299 for
<alpha-osf-managers_at_sws1.ctd.ornl.gov>; Mon, 25 Sep 1995 11:39:04 -0400
Received: from cleopas.cc.vt.edu by oaunx1.ctd.ornl.GOV (8.6.10/3.0-C)
id LAA13666; Mon, 25 Sep 1995 11:39:00 -0400
Received: by cleopas.cc.vt.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
id AA08192; Mon, 25 Sep 1995 11:38:28 -0400 (EDT)
Received: by NeXT Mailer (1.63.RR)
Date: Mon, 25 Sep 1995 11:38:28 -0400 (EDT)
From: mbox_at_cleopas.cc.vt.edu (Mike Box)
Subject: ADVFS
Sender: alpha-osf-managers-relay_at_sws1.ctd.ornl.gov
To: Alpha-OSF-Managers-List_at_cleopas.cc.vt.edu
Reply-to: mbox_at_cleopas.cc.vt.edu (Mike Box)
Message-id: <9509251538.AA08192_at_cleopas.cc.vt.edu>
Content-transfer-encoding: 7BIT
Followup-to: poster
Thanks to these who responded:
Craig I. Hagan <hagan_at_oec.com>
John Stoffel <john_at_wpi.edu>
Les Walker <walker_at_latrade.com>
Alan Rollow <alan_at_nabeth.cxo.dec.com>
My original question was:
I am using ADVFS (Advanced File Systems) to configure a new system with a "disk farm" that
contains 15 2G disks. These drives will support new applications using Oracle databases. Using
"disklabel", I partitioned each disk such that partitions a,b,d,e are 0.5G, and partitions f, g
are 1.0g. I have been given best GUESStamates of data requirements on 1G boundaries. Now for my
question:
Given that the data requirements are 1G quantities, and given that I doubt that this will end
up to be the true distibution of data, how bad of a performance hit will I take for, in the
name of flexibility, defining a domain with two partitions (say a and b) instead of one
partiotion (f)? I would like the flexibility of dynamically reacting to data distribution as it
becomes real, as opposed to (maybe) misappropriating disk space in large areas.
Responses:
--------------------------------------------------------------------------------
"Craig I. Hagan" <hagan_at_oec.com> said:
allocate space in Xmbyte increments (where is is some large
number such as 256,512,or 1024) via LSM. Then use the LSM
partitions for your advfs volumes. Then you win the ability to grow/shrink
advfs file domains and have raw partitions for oracle databases + the
ability to use ufs where needed (e.g. news).
--------------------------------------------------------------------------------
John Stoffel <john_at_wpi.edu> said:
Mike, I think you're overlooking the true power of Advfs and the extra
level of organization it gives you. In your case what I would do is take
a disk and make it into a domain consisting of the entire disk. Then,
make filesets in this domain to logically split up the data. Each
fileset can then have a quota set to limit it to a certain amount of
disk space. This lets you have flexibility in the future by merely
having to change the limits on the fileset without having to add new
domains.
Then as a domain starts to file up with filesets you have two
options. One is to merely add another volume to the domain. A volume
would be another disk, or part of another disk. Or you can move a
fileset from a full domain to a less full domain. This is not quite
as transparent to use the end user.
To put this into actuall commands:
# label the 2Gb disk
disklabel -rw rzX rzX
# make a domain usning the entire disk
mkfdmn /dev/rrzXc domain1
# make three filesets on the domain
mkfset domain1 set1
mkfset domain1 set2
mkfset domain1 set3
# give the first one a limit of 1Gb, the other two .75Gb, for a total
# potential space use of 2.5Gb
chfsets -B 1000000 domain1 set1
chfsets -B 750000 domain1 set2
chfsets -B 750000 domain1 set3
#hmm... we're running out of room
disklabel -rw rzY rzY
addvol /dev/rrzYc domain1
balance domain1
# but now we've got more space so add more more filesets.
mkfset domain1 set4
mkfset domain1 set5
...
--------------------------------------------------------------------------------
Les Walker <walker_at_latrade.com> said:
... I know that there's a balance command and a migrate command.
--------------------------------------------------------------------------------
Alan Rollow <alan_at_nabeth.cxo.dec.com> said:
I think you mean something like:
+---------------+
| |
| | A (.5 GB)
| | \
+---------------+ +-- Two volume domain.
| | /
| | B (.5 GB)
| |
+---------------+
| |
| |
| |
| | F (1 GB) -- Single volume domain.
| |
| |
| |
+---------------+
Ignoring possible performance differences in the physical
locations of sectors (see below), and ensuring that the two
A/B combination are adjacent, I would guess that the
difference in the two will be measureable. I think that
Advfs will attempt to distribute the files and data evenly
between the two volumes (A and B partitions). This may
cause a relatively long seek between two data allocations
that might have been nearly contiguous on the F partition.
With the Advfs Utilities, you could stripe files between
the two volumes, but striping on the same disk is of little
value and may hurt performance.
Now, if you used two A partitions on different disks to
construct a two volume 1 GB domain, this might offer
better performance since the load can be balanced between
two disks. And if you have the Utilities, striping can
be used to good affect if the nature of the files allows
it.
Below...
Most large capacity SCSI disks available today used zone
based recording to get their high capacities. This takes
advantage of the fact that the circumference of a circle
gets longer as the radius increases. It divides the disk
into zones which different number of sectors according to
how many will fit at the particular radius range. I think
early ZBR (banded) disks used 4 bands, but I've of recent
ones using 20 or more.
One affect of having more sectors per track in the out
cylinders, is that more data passes under the head per
revolution and the disk can provide higher data rates
for sequential transfers on the other outer tracks. For
some DSP disks the disk media rate varied between ~2 MB/
sec and ~5 MB/sec.
Depending on the I/O load and the disk geometry, some
partition may have better sequential data rates than
others.
--------------------------------------------------------------------------------
In response to the comments of Alan Rollow <alan_at_nabeth.cxo.dec.com> I said:
Is LSM an expensive (performance) solution? I suspect that disk
geometry issues still aplly here.
"raw partitions for oracle databases": Am I missing something?
Is ADVFS a bad choice for oracle databases?
--------------------------------------------------------------------------------
Alan Rollow <alan_at_nabeth.cxo.dec.com> I said:
> "raw partitions for oracle databases": Am I missing something?
> Is ADVFS a bad choice for oracle databases?
I've reordered these, since the Oracle question is the important. I
suspect Oracle prefers for customer to use raw disk partitions for
their databases. I suspect this is a combination of the belief that
raw disk is faster than going through a file system (often true) and
that it is the most reliable way of getting synchronous writes. It
also probably simplies their testing. To their credit, they can do
their own buffer management and may do a much better job than the
UNIX buffer cache.
I think most database vendors do support putting the database
files in a file system, but prefer raw partitions.
> Is LSM an expensive (performance) solution? I suspect that disk
> geometry issues still aplly here.
LSM is the Logical Storage Manager, a replacement for the Logical
Volume Manager that IBM submitted to the Open Systems Foundation
for their version of OSF and never worked to our satisfaction for
mirroring (but Digital has always been pretty paranoid about that
sort of thing). LSM is Veritas' VxVm repackaged and included Striping
and a nice GUI.
Received on Fri Sep 29 1995 - 12:48:12 NZST