ATARAID/FakeRAID/HPTRAID/PDCRAID as dm targets?

ATARAID/FakeRAID/HPTRAID/PDCRAID as dm targets?

[Carl-Daniel Hailfinger]

Hi,

[sorry for the crosspost]

a few hours ago I read on lkml that development to support ATARAID
variants as a dm target is underway. Is that correct? If not, I might be
interested in writing such a target.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

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

[Jeff Garzik]

Carl-Daniel Hailfinger wrote:
> Hi,
> 
> [sorry for the crosspost]
> 
> a few hours ago I read on lkml that development to support ATARAID
> variants as a dm target is underway. Is that correct? If not, I might be
> interested in writing such a target.

It's not underway AFAIK, but Arjan and I "keep meaning to do it."

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

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

[Kevin P. Fleming]

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...

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?

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

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 534 bytes --]


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...
> 
> 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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Wilfried Weissmann]

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...

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:

1. its all within evms
There is no need for additional tools required to setup the volume 
(thinking about installers and initrd...).

2. evms comes with partition handling.
Otherwise someone has to write another tool/library that does the 
partition setup.

3. it works for 2.6 and (patched) 2.4 kernels

4. nice clickety-click user interface
Especially useful for lazy people like me. ;)

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

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: 
What do you think?

Regards,
Wilfried

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

[Jeff Garzik]

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...
> 
> 
> 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?


Ideally yes.  I don't see an in-tree RAID1 dm target though....

	Jeff

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

[Carl-Daniel Hailfinger]

Jeff Garzik wrote:
> 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...
>>
>>
>> If these "soft" RAID implementations only support RAID-0/1/0+1/1+0, is

Not all of them. Some are RAID-5.


>> 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?
> 
> 
> Ideally yes.  I don't see an in-tree RAID1 dm target though....

IIRC, even a RAID-5 dm target is on its way to mainline and it was called
something like "the last step to obsolete md". So the userspace approach
seems the way to go.

That leaves me with the following questions:

- The kernel 2.4 code detects ATARAIDs by usage of deep kernel knowledge
about the specific harddisk (depending on the phase of the moon, it uses
head/sect/cyl or LBA). Is all of this info available to userspace?

- Would an EVMS plugin or a simple script calling dmsetup be the way to
go? If I go the dmsetup route, is there any chance to get partition
detection on top of the ATARAID for free (by calling another dm tool)?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

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

[Kevin P. Fleming]

Carl-Daniel Hailfinger wrote:

> - Would an EVMS plugin or a simple script calling dmsetup be the way to
> go? If I go the dmsetup route, is there any chance to get partition
> detection on top of the ATARAID for free (by calling another dm tool)?

This was posted a while back; I don't know what the status of it being 
merged into util-linux is.

http://lwn.net/Articles/13958/

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

[Måns Rullgård]

Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2004@gmx.net> writes:

> IIRC, even a RAID-5 dm target is on its way to mainline and it was called
> something like "the last step to obsolete md". So the userspace approach
> seems the way to go.

RAID6 was recently added to md.  Hmm...

-- 
Måns Rullgård
mru@kth.se

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

[Carl-Daniel Hailfinger]

Kevin P. Fleming wrote:
> Carl-Daniel Hailfinger wrote:
> 
>> - Would an EVMS plugin or a simple script calling dmsetup be the way to
>> go? If I go the dmsetup route, is there any chance to get partition
>> detection on top of the ATARAID for free (by calling another dm tool)?
> 
> 
> This was posted a while back; I don't know what the status of it being
> merged into util-linux is.
> 
> http://lwn.net/Articles/13958/


The two links below mention the same problems of partitions over dm:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107383495031133
http://marc.theaimsgroup.com/?l=linux-kernel&m=107384987212233

And here two links for partitions over md:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107401984323154
http://lkml.org/lkml/2003/11/13/182
And the patch to do partitions over md:
http://cgi.cse.unsw.edu.au/~neilb/patches/linux-devel/2.5/2004-02-03:03/006MdPartition

(Related to the problem mentioned earlier in this thread)
Christophe Saout seems to already have some prototype to handle ATARAID
devices in general:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107652932411321

Now the question is: How do we fit all of this together?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

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

[Carl-Daniel Hailfinger]

[forgot to include Christophe Varoqui in CC]

Carl-Daniel Hailfinger wrote:
> Kevin P. Fleming wrote:
> 
>>Carl-Daniel Hailfinger wrote:
>>
>>
>>>- Would an EVMS plugin or a simple script calling dmsetup be the way to
>>>go? If I go the dmsetup route, is there any chance to get partition
>>>detection on top of the ATARAID for free (by calling another dm tool)?
>>
>>
>>This was posted a while back; I don't know what the status of it being
>>merged into util-linux is.
>>
>>http://lwn.net/Articles/13958/

Christophe V.: What is the currrent status of your work?


> The two links below mention the same problems of partitions over dm:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107383495031133
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107384987212233
> 
> And here two links for partitions over md:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107401984323154
> http://lkml.org/lkml/2003/11/13/182
> And the patch to do partitions over md:
> http://cgi.cse.unsw.edu.au/~neilb/patches/linux-devel/2.5/2004-02-03:03/006MdPartition
> 
> (Related to the problem mentioned earlier in this thread)
> Christophe Saout seems to already have some prototype to handle ATARAID
> devices in general:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=107652932411321
> 
> Now the question is: How do we fit all of this together?


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

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

[christophe varoqui]

>>>>- Would an EVMS plugin or a simple script calling dmsetup be the way to
>>>>go? If I go the dmsetup route, is there any chance to get partition
>>>>detection on top of the ATARAID for free (by calling another dm tool)?
>>>
>>>This was posted a while back; I don't know what the status of it being
>>>merged into util-linux is.
>>>
>>>http://lwn.net/Articles/13958/
> 
> Christophe V.: What is the currrent status of your work?
> 
It mutated into kpartx, as I ported the compilation to klibc.
It is functionaly unchanged since that LWN report.

I know it works for partitioned multipath devmaps, partitioned loops, 
partioned md ...

It needs more testing and a lot of integration thinking.

regards,
cvaroqui

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

[Carl-Daniel Hailfinger]

christophe varoqui wrote:
>>>>> - Would an EVMS plugin or a simple script calling dmsetup be the
>>>>> way to
>>>>> go? If I go the dmsetup route, is there any chance to get partition
>>>>> detection on top of the ATARAID for free (by calling another dm tool)?
>>>>
>>>>
>>>> This was posted a while back; I don't know what the status of it being
>>>> merged into util-linux is.
>>>>
>>>> http://lwn.net/Articles/13958/
>>
>>
>> Christophe V.: What is the currrent status of your work?
>>
> It mutated into kpartx, as I ported the compilation to klibc.
> It is functionaly unchanged since that LWN report.
> 
> I know it works for partitioned multipath devmaps, partitioned loops,
> partioned md ...
> 
> It needs more testing and a lot of integration thinking.

Oh, you will get a lot of testing once I use kpartx to handle partitions
on top of ataraid. I'm aiming for a working solution at the end of this week.


Regards,
Carl-Daniel

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

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

[Jeff Garzik]

Carl-Daniel Hailfinger wrote:
> 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?

Unfortunately not, but I can get you in touch with somebody at Promise 
who can.  They're definitely interested in working with the open source 
community.  Not public...


> 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.

That's pretty nice.  Very Unix-ish:  provide a small, pluggable piece 
that does one thing, and does it well.


>>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.

Cool :)


>>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.

Agreed -- a minimal implementation is needed first anyway.  The BIOS of 
these proprietary RAID thingies typically provides the user interface.


>>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.

Feel free to ask me questions, too.

	Jeff

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

[Wilfried Weissmann]

Carl-Daniel Hailfinger wrote:
> Wilfried Weissmann wrote:
>>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.

Oh, well. My intention was to prevent that there is a set of new tools 
but instead to integrate what is required into an existing framework. 
And also to benefit from the system, like using the partition support 
that was already present in EVMS. Particulary this was the key factor in 
my decision for EVMS. Right now we have 3 places where partition 
(detection) code is located. Its in the kernel, its in EVMS and now 
there is also kpartx. Each implementation has its own features and 
goodies, but the problem is that they also have their own bugs. There is 
a wide set of partition types one wants to implement. So we end up in a 
point where we have dependencies on hardware and partition types. Like 
if you have hardware X you cannot use LDM and Solaris Slices but you can 
have BSD Disk Slices.

> 
> 
> 
>>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.

On the other hand this is not a big deal unless you do have embedded 
systems with tight hardware constraints. You can also strip evms a lot 
by removing unnecessary plugins. Installers can also have EVMS only on 
the installation media (unless your install source is on the RAID).

> 
> 
> 
>>2. evms comes with partition handling.
>>Otherwise someone has to write another tool/library that does the
>>partition setup.
> 
> 
> Well, kpartx is already written.

Right, but like I have already written above, I do not understand why 
one should not reuse existing code and therefor preventing code duplication.

> 
> 
> 
>>3. it works for 2.6 and (patched) 2.4 kernels
> 
> 
> Can't dispute that.

Support in both kernels enables one to make a smooth migration.

> 
> 
> 
>>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.

Well, I have to admit that I am also biased. You can still use the 
command line evms binary for scripting of course.

[snip]

>>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.

Not all features and supported hardware of the current ataraid code are 
going to be available in a matter of days (at least for my part). Indeed 
I am wondering if it might be desirable to use both implementations at a 
time during migration. This is why I was thinking about adding a config 
options that protects you from destroying data by error.

Regards,
Wilfried

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

[Wilfried Weissmann]

Jeff Garzik wrote:
> Carl-Daniel Hailfinger wrote:
> 
>>> 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.
> 
> 
> Agreed -- a minimal implementation is needed first anyway.  The BIOS of 
> these proprietary RAID thingies typically provides the user interface.

On the other hand EVMS allowed me to make a minimal solution by taking 
care of the partitioning and the DM-API in the EVMS framework. The user 
interface is just an add-on that comes with the package. Right now its 
just a way for the user to get a "look its really there". If we do the 
RAID configuration and writeing the configuration blocks to the disks or 
not is in your hands. When we consider this to be to risky then lets 
just skip it.

Regards,
Wilfried

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

[Pedro Larroy]

On Sat, Mar 20, 2004 at 03:51:19PM -0500, Jeff Garzik wrote:
> Carl-Daniel Hailfinger wrote:
> >Hi,
> >
> >[sorry for the crosspost]
> >
> >a few hours ago I read on lkml that development to support ATARAID
> >variants as a dm target is underway. Is that correct? If not, I might be
> >interested in writing such a target.
> 
> It's not underway AFAIK, but Arjan and I "keep meaning to do it."
> 
> 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

Hi.

Are those available with or without NDA?

Regards.
-- 
Pedro Larroy Tovar | Linux & Network consultant |  piotr%member.fsf.org 

Software patents are a threat to innovation in Europe please check: 
	http://www.eurolinux.org/     

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

[Carl-Daniel Hailfinger]

Wilfried Weissmann wrote:
> Jeff Garzik wrote:
> 
>> Carl-Daniel Hailfinger wrote:
>>
>>>> 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.
>>
>>
>>
>> Agreed -- a minimal implementation is needed first anyway.  The BIOS
>> of these proprietary RAID thingies typically provides the user interface.
> 
> 
> On the other hand EVMS allowed me to make a minimal solution by taking
> care of the partitioning and the DM-API in the EVMS framework. The user

After having written a generic standalone solution (currently in testing)
with less code than the evms plugin, I have my doubts about EVMS allowing
minimal solutions. It seems most of your plugin is just code to make EVMS
happy and I was frightened by that.

> interface is just an add-on that comes with the package. Right now its
> just a way for the user to get a "look its really there". If we do the
> RAID configuration and writeing the configuration blocks to the disks or
> not is in your hands. When we consider this to be to risky then lets
> just skip it.

Please do not misunderstand my intentions. I appreciate your code very
much and tried to reuse as much of it as possible (and tried to keep my
modifications small), and if you plan on integrating my generic code into
EVMS you're most welcome (I would feel honoured).

However, my goals were (in that order):
1. Spit out a list of devices that have some sort of RAID magic
2. Group the devices by array
3. Set up a device corresponding to /dev/araraid/d0

and keep the code generic and independent enough so that it can be
integrated into EVMS or used standalone with only a few changes.

Code will follow once I get step 3 working generically.
Step 1 is done (I have some trouble finding the superblock on small
PDCRAID arrays, will ask Jeff).
Step 2 is done (modulo implementation bugs not yet found)
Step 3 is partly done (It only works for striped Highpoint arrays because
I didn't have the hardware available until now)


Regards,
Carl-Daniel

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

[Carl-Daniel Hailfinger]

Jeff Garzik wrote:
> Carl-Daniel Hailfinger wrote:
> 
>> 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?
> 
> Unfortunately not, but I can get you in touch with somebody at Promise
> who can.  They're definitely interested in working with the open source
> community.  Not public...

Could you please send me the contact information via private mail?
Thanks.

>> 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.
> 
> 
> Feel free to ask me questions, too.

OK. First question: calc_pdcblock_offset calculates the superblock
location based on capacity, sectors and heads. However, the same machine
which showed 255 heads under Kernel 2.4 now shows only 16 heads and some
of the hardcoded location calculation routines may fail. Is there a
userspace generic method for finding the right sector?
(It works sometimes for me.)

If the answer to above question is also considered confidential, please
feel free to NOT answer to the list.


Regards,
Carl-Daniel

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

[Jeff Garzik]

Carl-Daniel Hailfinger wrote:
> Jeff Garzik wrote:
> 
>>Carl-Daniel Hailfinger wrote:
>>
>>
>>>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?
>>
>>Unfortunately not, but I can get you in touch with somebody at Promise
>>who can.  They're definitely interested in working with the open source
>>community.  Not public...
> 
> 
> Could you please send me the contact information via private mail?
> Thanks.

Will do.


>>>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.
>>
>>
>>Feel free to ask me questions, too.
> 
> 
> OK. First question: calc_pdcblock_offset calculates the superblock
> location based on capacity, sectors and heads. However, the same machine
> which showed 255 heads under Kernel 2.4 now shows only 16 heads and some
> of the hardcoded location calculation routines may fail. Is there a
> userspace generic method for finding the right sector?
> (It works sometimes for me.)

The standard method one uses to calculate cyl/head/sect in ATA, AFAIK. 
If that changes between 2.4 and 2.6, that sounds like a bug unrelated to 
the code you're writing...

	Jeff