--/WwmFnJnmDyWGHa4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, May 12, 2001 at 09:18:34PM -0000, Tyler Mitchell wrote:

> I'm trying to get a couple partitions concatenated together and
> am having trouble figuring out what the interleave factor should
> be.  I have two 1GB IDE hard drives with identical disklabels.=20
> I am trying to concatenate both "e" partitions on each disk.

If you have identical drives, you'd probably be *much* better off
using raid(4) instead of ccd(4).  I believe the author of ccd,
Jason Thorpe, has said, basically, that it was a cool idea, and
nifty technology, but that RAID is really what's designed for the job.
(Apologies if I'm misquoting here.)

As far as optimum interleaves go, that's the subject of plenty of
research.  The bottom line is to try different numbers and see what
works best for you.  There are some guidelines, though.  I'll see how
many of them I can get right:

> The ccd(4) manpage states: "the optimum interleave factor is
> typically the size of a track."  This would be fine, but I'm not
> really sure how to determine the size of a track.

The rationale here is probably that a disk can (hopefully) read and
transfer a track all at once.  This may be more true for SCSI disks
than IDE, but I'm not really sure.  To find the track size, check
your disklabel output, or your boot messages (check dmesg(8)).  Keep
in mind, however, that nearly all disks you'll encounter nowadays
have varying track sizes.  The cylinders near the center of the disk
have shorter tracks, because they want to keep the data density roughly
the same on all parts of the disk.  But manufacturers make guesses at
an optimum number for their disks to report as the "track" size, and
it probably won't hurt to take their advice.

In dmesg output, you'll see numbers for cylinders, heads, and sectors.
The sectors number is the number of sectors in a track.

> At http://www.netbsd.org/Documentation/misc/ it states: "48
> works fine for me with two disks. AFAIK with 16 and some other
> numbers it can happen that all inodes will be on the same disk,
> which should be avoided for performance reasons. IIRC I got some
> problems, if the number of sectors of an component is not a
> multiple of the interleave."

The inode of a ufs type of filesystem stores the file metadata, as well
as info on where the actual data resides on disk.  So, for instance, if
you're scanning your disks looking at filenames, modification times,
sizes, and the like, but not actually opening your files, you'll be hitting
inodes, but nothing else.  So if all your inodes are on one disk, you
just flog that one disk.  Inodes are pre-allocated on the filesystem
when you run newfs.  The algorithm is explained in the 4.4BSD book, I
think.  That may exist under our /usr/share/doc.

The second part of the statement seems to imply that there needs to be
a whole number of interleaves on each component disk in your array.  So,
if you choose an interleave of 48, your component disks should be multiples
of 48 sectors in size.  Keep in mind that you should be using partition
e of the component disks to build your array, not d or c (the "whole-disk"
partitions).  So just shrink your e partition until it's a multiple of your
interleave.  Who cares if you lose 5KB on the end of a 1GB disk?

Pretty much all of this advice should hold true for raid, as well as ccd.

Just make sure you experiment around with your raid array before you put
it in production.  You want to know how to deal with emergencies *before*
they happen.  And it's good to get a feel for the kind of performance
you're going to get from your RAID array.

Chris

--=20
---------------------------------------------------- chris@cjones.org
Chris Jones                                          Mad scientist at large
  www.netbsd.org www.postgresql.org www.schemers.org www.python.org

--/WwmFnJnmDyWGHa4
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (NetBSD)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjr+EVgACgkQDPY2T8RzaD92LgCeMf/Tz/BjuWYXAEiVJCe2AewS
FfEAoI1K7DbyMPqIIWB42OAeVMEs4aPl
=wLXZ
-----END PGP SIGNATURE-----

--/WwmFnJnmDyWGHa4--