Messages in this thread | | | Date | Mon, 22 Mar 2004 20:14:36 +0100 | From | Carl-Daniel Hailfinger <> | Subject | Re: ATARAID/FakeRAID/HPTRAID/PDCRAID as dm targets? |
| |
Wilfried Weissmann wrote: > Arjan van de Ven wrote: > >> On Sat, Mar 20, 2004 at 07:23:01PM -0700, Kevin P. Fleming wrote: >> >>> Jeff Garzik wrote: >>> >>> >>>> So go ahead, and I'll lend you as much help as I can. I have the >>>> full Promise RAID docs, and it seems like another guy on the lists >>>> has full Silicon Image "medley" RAID docs...
Jeff: May I request your docs?
> I am the only one without docs? Oh, Crap! > >>> >>> If these "soft" RAID implementations only support RAID-0/1/0+1/1+0, >>> is there really any need for a new DM target? Wouldn't you just need >>> a userspace tool to recognize the array and do the "dmsetup" >>> operations to make it usable? >> >> >> >> the later. > > > Why not join my evms-plugin work? This has 4 advantages over the > "stand-alone binary" approach:
Well, I had something in mind which closely resembles the ataraid-detect tool Thomas Horsten (Medley RAID) suggested.
http://lists.infowares.com/archive/medley/2004-February/000001.html
OK, I was even aiming for less: Write an ataraid-detect tool which outputs the correct mapping for dmsetup. If I manage to write it generically enough, it can be integrated into evms or used as a standalone program, whatever you like.
> 1. its all within evms > There is no need for additional tools required to setup the volume > (thinking about installers and initrd...).
The EVMS sample initrd is HUGE. (2.1 MB) I'm aiming for a initrd size of less than 1/10 of that.
> 2. evms comes with partition handling. > Otherwise someone has to write another tool/library that does the > partition setup.
Well, kpartx is already written.
> 3. it works for 2.6 and (patched) 2.4 kernels
Can't dispute that.
> 4. nice clickety-click user interface > Especially useful for lazy people like me. ;)
I prefer the "no user interface" approach. But then again, I'm biased.
> My plugin has to be a bit redesigned to allow easier integration of > support code for other controllers. What is required is basically to > split the plugin in a common and a per-controller module. No big deal. > Or we can make a new plugin for every controller... > > see: http://marc.theaimsgroup.com/?l=evms-devel&m=107936928618685&w=2
I downloaded the code and am playing with it right now.
> Apropos: If we do evms plugins then we might want to have the > possibility to detect if some ataraid module aleady has picked up the > disk. In this case we should not create a volume because of someone > might try to mount the same volume via the ataraid and evms devicefiles > which leads to filesystem corruption. I thought about makeing a /proc > ataraid entry that contains the claimed disks. I think this should be > supported by all ataraid modules if this is done so I am asking you:
That's one of the problems that made me look for a 2.6-only solution. This way, you won't get the problems described above.
> What do you think?
I'll use your work as a foundation. First step is integrating detection for non-HPT arrays. If the code looks too messy after that, I still can refactor it.
As soon as I have some code to get at least PDCRAID working, I'll post again.
Regards, Carl-Daniel
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |