[K12OSN] Are fast disks really that important and why?

[john]

Thank you for the very thoughtful reply Les. It gives me food for thought.

John

On 5/31/07, Les Mikesell <les at futuresource.com> wrote:
> john wrote:
>
> > However a unix guru I work with responded to me:
> >
> > "But--at least in all the UNIXen I ever worked on--you can and do implement
> > this in software. And not in hardware."
>
> I don't think the current Linux implementations do a very good job of
> re-ordering seeks if it even tries at all.  However, it does buffer to
> whatever extent that it can.  Writes are always buffered unless there is
> no RAM left (and the flush to disk might be done in sector order so you
> would get some re-ordering there).  Reads are held in the disk buffer
> until the space is needed for something else, so additional RAM can make
> a huge difference when multiple users frequently access the same things.
>
> The difference with SCSI is that the controller can re-order queued
> commands after the CPU sends them so a read request for something
> between two pending requests might be serviced as the head goes past its
> location.  My recommendation is to max out the RAM you can put in the
> box first, then if you have money left go for the faster drive set.
>
> > To prove his point we did the following:
> >
> > We tested our installation in a lab with 30 thin clients attached to a
> > single commodity workstation running ubuntu/ltsp4.2 with 2G ram, 3Ghz
> > processor. We used  vmstat to monitor CPU,memory usage and disk i/o.
> > We found that disk I/O was relatively light after application startup
> > and that slow downs began to happen as processes queued up behind the
> > CPU waiting for their time slice to be handled. In short client speed
> > fell off as the CPU got busier, and not because of busy disks.
> >
> > Were we looking at this in the wrong way? Was there a better way to
> > determine Disk IO?
> >
> > I am leaning toward getting a fast array, but I would like to
> > understand this better before I do.
>
> Iostat will show i/o per-device but neither will give a good measure of
>     the time that seeks are wasting which is the real problem.  If you
> had a
> matching load on a SCSI and IDE machine you might be also able to see a
> difference in the system interrupts and context switch columns of vmstat
> as the CPU has to do a lot more to drive an IDE controller (like issue a
> seek and wait for completion before starting the data transfer) and each
> of those operations involves an interrupt and context switch.
>
> --
>    Les Mikesell
>     lesmikesell at gmail.com
>
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
>