On Tuesday, 11 December 2001 at 15:34:37 +0100, Wilko Bulte wrote:
> 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.
So what did it do with user requests which crossed stripes?
Greg
--
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
