On 05.10.2011 11:58, Lev Serebryakov wrote: > Hello, Miroslav. > You wrote 5 октября 2011 г., 12:24:06: > >>> What RAID do you mean exactly? geom_stripe? geom_mirrot? geom_raid? >>> Something else? >> I am mostly using geom_mirror. > [SKIPPED] > Oh, I see. Unfortunately, there is no GEOM metadata infrastructire, > GEOMs are too generic for this. I could design some meta-meta > framework, and unify all RAID classes with "intenral" metadtata > (geom_stripe, geom_concat, geom_mirror, geom_raid3 and my external > geom_raid5) to use it. In such case it will work -- kernel will not > pass providers with "ditry" metadtata to any GEOMs, but owners, for > tasting. Of course, classes like geom_part and geom_raid could not be > changed in such way -- they are forced to use pre-defined metadata > formats. geom_raid addresses this problem in own way. As soon as RAID BIOSes expect RAIDs to be built on raw physical devices and probe order is not discussed, geom_raid exclusively opens underlying providers immediately after detecting supported metadata. So even if volume is broken or incomplete or this disk marked failed, or in any other case, this disk won't be accessible for other GEOM classes. If administrator wishes to reuse this disk for any other purpose, he should explicitly erase on-disk metadata using graid tool or with dd after unloading geom_raid. Up to the recent time geom tools didn't report geoms without providers. Now there is special "-a" argument to report all of them. Also there is "-g" to report geoms instead of providers, that is useful in such cases. > It is good idea, but it should be separate project. And, yes, it > will change metadata format for these GEOMs, so it will not be > backward-compatible. > > And, yes, it seems to be much more intrusive change in GEOM > subsystem (because it will change tasting sequence), and should be > supervised by other developers from very beginning. > > I could write proposal in near future, with some design notes. -- Alexander MotinReceived on Wed Oct 05 2011 - 07:19:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:18 UTC