I/O parallelism: was: [AFS3-std] Re: [OpenAFS-devel] convergence of RxOSD, Extended Call Backs, Byte Range

[Matthew Andrews]

... stuff cut here ...
>>
>> 2b) Tom raised the question of support for parity computation in
>> support of raidn OSD implementation.  Clearly this could make the
>> protocol substantially more useful for some applications.  Is it
>> possible that we should incorporate placeholders for this?  Tom, do
>> you have ideas about what would be required?
>>     
>
> That would have to happen in the cache manager, I suppose. Could be
> quite slow/expensive. All modern RAID systems use specialized chip sets
> for doing it. The reason certainly is that normal computer CPUs are not
> fast enough.
>
> Hartmut
>
>   
actually a number of the latest RAID systems are moving to doing this in
software using simd instructions and/or lookup tables. it turns out that
in the end it's hard to beat the commodity computing curve even in as
dedicated an application as raid5/6 calculations. it's amazing what you
can do with QP interfaces, and 8-32 cores.

-Matt Andrews
>> (and, what if it fails?  see II.3)
>>
>> 3) Tom raised the question of support for data journalling.  Perhaps
>> this seems way-out-there, but in fact, the current generation of
>> local file system technology actually supports low-cost point-in-time
>> snapshot functionality.  In that context, I think I can imagine
>> (achievable) implementations supporting a protocol in which the
>> transaction boundary is extended to the component I/O servers (OSDs)
>> and commit/rollback semantics were implemented on it.  I think it
>>     

... stuff cut here ...