... 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 ... _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
