Re: ATARAID/FakeRAID/HPTRAID/PDCRAID as dm targets?

[Carl-Daniel Hailfinger]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/