On Tue, Dec 11, 2001 at 11:06:33AM +1030, Greg Lehey wrote: > On Monday, 10 December 2001 at 10:30:04 -0800, Matthew Dillon wrote: > > > >>> performance without it - for reading OR writing. It doesn't matter > >>> so much for RAID{1,10}, but it matters a whole lot for something like > >>> RAID-5 where the difference between a spindle-synced read or write > >>> and a non-spindle-synched read or write can be upwards of 35%. > >> > >> If you have RAID5 with I/O sizes that result in full-stripe operations. > > > > Well, 'more then one disk' operations anyway, for random-I/O. Caching > > takes care of sequential I/O reasonably well but random-I/O goes down > > the drain for writes if you aren't spindle synced, no matter what > > the stripe size, > > Can you explain this? I don't see it. In FreeBSD, just about all I/O > goes to buffer cache. > > > and will go down the drain for reads if you cross a stripe - > > something that is quite common I think. > > I think this is what Mike was referring to when talking about parity > calculation. In any case, going across a stripe boundary is not a > good idea, though of course it can't be avoided. That's one of the > arguments for large stripes.
In a former life I was involved with a HB striping product for SysVr2 that had a slightly modified filesystem that 'knew' when it was working on a striped disk. And as it know, it avoided posting I/O s that crossed stripes. W/ -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message