On Apr 23, 2010, at 7:50 AM, John Baldwin wrote: > On Thursday 22 April 2010 11:31:37 am Alexander Motin wrote: >> If ataraid(4) should be reimplemented in GEOM, then how exactly? One >> more separate RAID infrastructure in GEOM (third?) looks excessive. >> Reuse gmirror, gstripe,... code would be nice, but will make them more >> complicated and could be not easy for RAID0+1 (due to common metadata) >> and RAID5 (due to lack of module in a base system). > > Scott's view (which sounds good to me) is that GEOM should include a library > of routines for working with common transforms such as RAID1, striping, etc. > Each ATA RAID vendor format would then consist of a small GEOM module that > used the library routines to manage all the I/O and the bulk of the module > would be managing a specific metadata format. > THIS It's hard for me to talk about RAID and FreeBSD without getting into a long sermon, so I'll try to keep this short. RAID is about data integrity, not about mirror/stripe/parity algorithms. Those algorithms are just a small part of RAID, and are merely tools for achieving the goals of RAID. But RAID != algorithms. It's like how we use linked lists extensively within the kernel, but the kernel != linked lists. A well-designed software raid stack is going to be an engine that manages topology, executes and rolls back I/O transactions, and handles error recovery. On-disk metadata is again just an algorithm that is part of this whole picture, and should be modularized as such along with the transforms. And to be even more brief, the existing GEOM RAID modules are designed in completely the wrong direction from this. Caveat Emptor. ScottReceived on Fri Apr 23 2010 - 12:23:36 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:03 UTC