On Fri, Oct 29, 1999 at 03:50:36AM +0200, Thomas Waldmann wrote:
> > If you run two bonnies you will see that your read performance gets better
> > (well the sum of the read performance will be superior to that of one disk).
>
> The question in that case is: is that because of superior RAID1 transfer rate or
> because of the fact, that 2 bonnies run on the same disk would produce
> additional seeks, lowering single disk performance !?
Two bonnies (like much real-world usage) will produce lots of seeks yes.
With RAID-1 the seeks can be spread out.
But I think I should submit a benchmark on this... This is all out of memory
and what I _think_... Not entirely viable in a discussion...
> > RAID-1 will distribute reads to the two disks, but it's not a gain if you
> > only read one consecutive piece of data.
>
> Why ?
In order to distribute reads, each disk must skip (seek past) the data the
other disk just read. With small reads (well smaller than some hundred KB)
this is a lot of seeks.
>
> If I want to have a big block of data (say 1MB), couldn't the requests be
> spread on both mirrored disks to effectively double transfer rate ?
Yes if the kernel knew beforehand that bonnie would keep on reading.
But there are lots of optimizations that can be done with a psychic kernel. :)
>
> > If the two disks should share the reading, they should seek all the time
> > (disk A should skip the blocks disk B > just read). That doesn't improve
> > read performance.
>
...
>
> IF one could spread requests so that they will match geometry, one could issue
> requests track-wise:
> disk A reads ONLY cyl x head 2*n
> disk B reads ONLY cyl x head 2*n+1
>
> Problem: physical disk geometry today is
> - unknown to SW / SCSI controller
> - no easy thing (more sectors on outer tracks than on inner tracks)
- and maybe track-to-track seek time is still above one-track-read-time
Ideally you would do a several-MB readahead, and then have each disk do
a few MB consecutive read each.
But I'm not sure this would be very ideal in a real-world situation.
Thinking in terms of optimizing bonnie results may lead to optimizations that
turn out not to be optimizations at all, in a real world environment.
> So I think this would be quite hard to fully exploit via software.
>
> But this means:
>
> If one uses quite small requests spread onto two mirror disks, it doesn't get
> faster due to "skipping" of sectors, lowering data xfer rate.
>
> But that should get better (although never optimal) if request size is about
> physical track size, so sektor skipping is less (but more head switches occur
> and it doesn't take different time if you switch from head 1 to 2 or
> from 1 to 3). Also it should be OK if request size is about cylinder size,
> assuming that a seek to next cylinder isn't much faster than a seek skipping
> one cylinder.
Reads should be so large that the seek time is insignificant compared to the
read time.
>
> So how do I change request size given to disk subsystem ? Is that the same as
> the "chunk size" in case of RAID-1 ?
Increasing chunk-size would give you some of this. If the kernel was tweaked
to read odd chunk numbers from odd disk numbers etc. and you used a 512K/1M/?
chunk-size, you would probably see some of this improvemenet.
But I seriously doubt it would be any good for anything else but bonnie.
> If yes, I'm still wondering: I tried 4KB, 32KB and 128KB - no big difference.
> Maybe I should get some physical geometry data of my disks and try to calculate
> some reasonable value (as far as possible).
But AFAIK the kernel doesn't distribute the reads to different disks now, when
reading consecutive data.
> > However, if concurrent reads take place, you will see a performance gain
> > from the read distribution.
>
> Yes, because 2 hdds can seek twice as often as 1 can. But you don't need RAID-1
> for that - just using 2 separate disks for different tasks already does that.
Yep, but two different disks aren't redundant. If you want performance only,
go with raid-0, linear, or simply two separate disks as you said.
> > Remember, an N disk RAID-0 is N times more prone to failure than one single
> > drive. This gets ugly when you have many disks, especially because you'll
> > likely loose the entire filesystem if a disk goes down.
>
> Yes, I know ...
>
> BTW: this is also something to think about with RAID-5: the more disks you use,
> the more likely one (or even two) of them will fail. Making a single RAID-5 out
> of many disks is of course MUCH more safe than making a RAID-0 out of them -
> but still no good idea. One should only make medium disk-count RAID-5 arrays
> (low count wastes to much space and also has low performance, high count is more
> likely to have single or double disk failures [and maybe has too much
> performance for you SCSI channels ;-] ).
It's a compromise I guess.
The paranoid run RAID-1 with ten disks to allow for nine simultaneous disk failures :)
--
................................................................
: [EMAIL PROTECTED] : And I see the elder races, :
:.........................: putrid forms of man :
: Jakob �stergaard : See him rise and claim the earth, :
: OZ9ABN : his downfall is at hand. :
:.........................:............{Konkhra}...............:
