[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tru64-unix-managers
Subject:    SUMMARY: disklabel rpm value
From:       Tru64 User <tru64user () yahoo ! com>
Date:       2001-09-28 17:44:28
[Download RAW message or body]

I received to very descriptive replies, thanks to
Alan@nabeth and Jesper Nemholt. Thanks compaq for
monitoring this list. I have included them in entirety
below.
_Thanks


--- "Nemholt, Jesper Frank"
<JesperFrank.Nemholt@compaq.com> wrote:
> > -----Original Message-----
> > From: Tru64 User [mailto:tru64user@yahoo.com]
> > Sent: viernes, 28 de septiembre de 2001 18:38
> > To: tru64-unix-managers@ornl.gov
> > Subject: disklabel rpm value
> > 
> > 
> > Hi,
> > Just wandering....
> > This is from a no-problem raid5 array on hsz70,
> > disk type DS-RZ1FB-VW ie. 36.4GB, 7600rpm drive.
> > Same results for a 10,000rpm drive in the same
> shelf.
> > I understand that hsz70 presents to the host the
> raid5
> > unit. 
> > 
> > 1. What does the reading of rpm=3600 from
> disklabel
> > tell me?
> 
> The disk speed if the disk is directly connected.
> Allways 3600 if the disk
> in reality is a RAID device.
> 
> > (Depending on #1) a. So if host sees both with
> > 3600rpm, where is the advantage of using either
> 7.2k
> > or 10k?
> 
> It's unable to tell what the speed of the disks
> behind a RAID device run at,
> so it just defaults to 3600.
> I agree it would be better if it didn't write
> anything at all, instead of
> writing something that is (usually) wrong.... but
> then, I didn't write the
> disklabel program ;-)
> 
> > 2. Is there an effect of mixing rpms within a raid
> > array?
> 
> Yes, and usually bad.
> Example :
> 
> When running RAID-5 you have data and parity
> distributed among all members
> of the raidset. When writing, the write doesn't
> complete until all members
> have written their part, and hence a slow device
> among fast devices will
> cause the fast devices to just idle until the slow
> device is finished....
> result is bad performance.
> 
> ...so it's allways best to use identical devices to
> ensure they finish more
> or less at the same time at any task.
> 
> > 3. Is there a way to check progress of rmvol
> (%wise)?
> > (-v)slows down process, but, would it have shown
> the
> > progress report? Just want to estimate and know
> what
> > times I should come in over the weekend to
> continue
> > operation.
> 
> You may be able to use showfdmn at the same time to
> see the amount of bytes
> being transferred off the volume you're removing,
> but I'm not really sure
> whether it updates during a rmvol or just
> afterwards.
> 
> --  
> Un saludo / Venlig hilsen / Regards
> 
> Jesper Frank Nemholt
> Unix System Manager
> Compaq Computer Corporation
> 
> Phone : +34 699 419 171
> E-Mail: JesperFrank.Nemholt@compaq.com 


   From:
         alan@nabeth.cxo.dec.com | Block Address  |
Add to Address Book





        1.  One of:

                o  The label was initialized on a
version of Tru64
                   UNIX that didn't know how to get
the rotational
                   from the disk and thus defaulted
very disk to
                   3600 rpm.

                o  The operating system did know how
to get the data,
                   but the HSZ didn't know how to
present it.  So,
                   fell back on the trusty 3600 rpm.

                o  The HSZ did know how to present a
value, but didn't go
                   to the trouble of providing an
accurate value; it
                   lied.

                o  The HSZ did know how and tried to
present a reasonable
                   value, but had more than one value
to choose from
                   and took a guess.

        1a. The better question is "is the disklabel
rotational speed
            relevant"?

            With respect to the base system I/O
consumers, only if you're
            using UFS and only if you set rotdelay to
a non-zero value.
            It is a value in the disklabel; doesn't
mean anything actually
            uses it.  The host can't order the disks
to slow down to some
            arbitrary expected speed.  It isn't going
to waste code on
            making rotational latency and media data
rate appear to be
            coming from a 3600 rpm disk unless there
is some significant
            advantage to it (*).

            The only place that I know that cares is
the code built
            into UFS that allocates data to take into
account rotational
            delays between blocks or strings of
blocks.  When disks
            started doing their own caching, this
feature became pretty
            worthless.

            And, if you don't like 3600 rpm, you can
change it.
  
        2.  Rotational speed affects latency when
waiting for a sector
            to rotate past.  It also affects the media
data rate.  If
            an array is mixed devices, some may
respond to comparible
            commands at different times.  You're
working with small
            statistical differences here, so the
affect may not be
            measureable or significant to be
interesting.  However,
            anybody that does benchmarking for a
living that knows
            a test can be constructed to prove
anything you want.

                There are lies, damned lies and
statistics.

                                        (I forget who
said it, a
                                         British PM
from the 1800s,
                                         I think).

        3.  Haven't a clue.

        (*) Usually high security or audio-visual
applications that
            require constant I/O rates.


=====


__________________________________________________
Do You Yahoo!?
Listen to your Yahoo! Mail messages from any phone.
http://phone.yahoo.com

[prev in list] [next in list] [prev in thread] [next in thread]