Bad Bod | 22 Apr 21:05 2014

Via RAID

Hi,
  Any update on this?

Via 8237 RAID checksum error.

I have moved on so can longer confirm any fix.

Now I moved to SSD I would like to know if I can RAID 0 on AMD SB950 southbridge.



Regards
David
_______________________________________________
Ataraid-list mailing list
Ataraid-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list
HERVE Stephane (AREVA | 12 Jun 19:13 2013

Problem with dmraid volumes at boot time

Hi all,
on Saturday we had our annual reboot of my NFS server which is on RedHat 5.2 (kernel 2.6.18-92).
Since I'm in big trouble because my server does not recognize his dmraid volumes at boot time.
I know that my disks are ok (made diag from my LSIlogic controller) and that my datas are there
(because when I boot on install CD, I can see my all datas even if I still have some errors).
When I look into the rc.sysinit file, I can see that the dm_resolve_name function does not return
anything. In fact it's the command
dmsetup table
in this function which does not return anything. I think it's not the right way, but maybe it is, I hope
you can explain it to me.
Here are the output of some dmraid commands when I finally finish my boot :
 
# dmraid -r
/dev/sda: ddf1, ".ddf1_disks", GROUP, ok, 583983104 sectors, data <at> 0
/dev/sdb: ddf1, ".ddf1_disks", GROUP, ok, 583983104 sectors, data <at> 0
/dev/sdc: ddf1, ".ddf1_disks", GROUP, ok, 583983104 sectors, data <at> 0
/dev/sdd: ddf1, ".ddf1_disks", GROUP, ok, 585806427 sectors, data <at> 0
/dev/sde: ddf1, ".ddf1_disks", GROUP, ok, 585806427 sectors, data <at> 0
/dev/sdf: ddf1, ".ddf1_disks", GROUP, ok, 585806427 sectors, data <at> 0
# dmraid -s
*** Group superset .ddf1_disks
--> Subset
name   : ddf1_4c53494c4f4749431000005010003110000047bef3103289
size   : 1751949312
stride : 128
type   : stripe
status : ok
subsets: 0
devs   : 3
spares : 0
--> Subset
name   : ddf1_4c53494c4f4749431000005010003110000047d1d930979b
size   : 1751949312
stride : 128
type   : stripe
status : ok
subsets: 0
devs   : 3
spares : 0
# dmraid -tay
ddf1_4c53494c4f4749431000005010003110000047bef3103289: 0 1751949312 striped 3 128 /dev/sda 0 /dev/sdb 0 /dev/sdc 0
ddf1_4c53494c4f4749431000005010003110000047d1d930979b: 0 1751949312 striped 3 128 /dev/sdd 0 /dev/sde 0 /dev/sdf 0
# fdisk -l /dev/sda
 
Disk /dev/sda: 300.0 GB, 300000000000 bytes
255 heads, 63 sectors/track, 36472 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1      109054   875974655+  8e  Linux LVM
# fdisk -l /dev/sdd
 
Disk /dev/sdd: 300.0 GB, 300000000000 bytes
255 heads, 63 sectors/track, 36472 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
 
   Device Boot      Start         End      Blocks   Id  System
/dev/sdd1               1      109054   875974655+  8e  Linux LVM
An the errors I get in /var/log/messages :
 
kernel:  sda: p1 exceeds device capacity
........
kernel:  sdd: p1 exceeds device capacity
........
kernel: attempt to access beyond end of device
 
My system see /dev/sda1 and /dev/sdd1 like partitions of a single disk of 300Go and not like a member
of a dmraid volume of 3 disks.
How can I do to make my system recognize these volums ? And why it doesn't while from an install CD
averything seems almost ok ?
Thanks in advance if you can help me.
 
Regards.
 

S.HERVE

AREVA TA - DP/SI/EMI

stephane.herve <at> areva.com

+33 (0)442602647

+33 (0)777390285

 
_______________________________________________
Ataraid-list mailing list
Ataraid-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list
Dead Gardens | 25 Apr 06:52 2013
Picon

Rebuilding a Raid 1

I'm trying to rebuild a raid 1 (dmraid+isw) unsuccessfully. I replaced the failed disk with a new one and the BIOS added it automatically to the raid. Running kernel 2.6.18-194.17.4.el5.


# dmraid -r


/dev/sda: isw, "isw_babcjifefe", GROUP, ok, 1953525165 sectors, data <at> 0
/dev/sdb: isw, "isw_babcjifefe", GROUP, ok, 1953525165 sectors, data <at> 0

# dmraid -s
*** Group superset isw_babcjifefe --> Subset name : isw_babcjifefe_Raid0 size : 1953519616 stride : 128 type : mirror status : nosync subsets: 0 devs : 2 spares : 0 When i try to start the raid i receive the next errors
# dmraid -f isw -S -M /dev/sdb
ERROR: isw: SPARE disk must use all space on the disk # dmraid -tay
isw_babcjifefe_Raid0: 0 1953519616 mirror core 3 131072 sync block_on_error 2 /dev/sda 0 /dev/sdb 0 # dmraid -ay
RAID set "isw_babcjifefe_Raid0" was not activated ERROR: device "isw_babcjifefe_Raid0" could not be found # dmraid -f isw -S -M /dev/sdb
ERROR: isw: SPARE disk must use all space on the disk # dmraid -R isw_babcjifefe_Raid0 /dev/sdb
ERROR: disk /dev/sdb cannot be used to rebuilding # dmesg
device-mapper: table: 253:13: mirror: Device lookup failure device-mapper: ioctl: error adding target to table device-mapper: ioctl: device doesn't appear to be in the dev hash table. device-mapper: table: 253:13: mirror: Device lookup failure device-mapper: ioctl: error adding target to table device-mapper: ioctl: device doesn't appear to be in the dev hash table. device-mapper: table: 253:13: mirror: Device lookup failure device-mapper: ioctl: error adding target to table device-mapper: ioctl: device doesn't appear to be in the dev hash table. device-mapper: ioctl: device doesn't appear to be in the dev hash table. device-mapper: ioctl: device doesn't appear to be in the dev hash table. Disks:
Disk /dev/sda: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes LVM:
PV /dev/sda5 VG storage lvm2 [914.64 GB / 28.64 GB free] Total: 1 [914.64 GB] / in use: 1 [914.64 GB] / in no VG: 0 [0 ] Reading all physical volumes. This may take a while... Found volume group "storage" using metadata type lvm2 ACTIVE '/dev/storage/home' [68.00 GB] inherit ACTIVE '/dev/storage/home2' [68.00 GB] inherit ACTIVE '/dev/storage/home3' [68.00 GB] inherit ACTIVE '/dev/storage/home4' [68.00 GB] inherit ACTIVE '/dev/storage/home5' [68.00 GB] inherit ACTIVE '/dev/storage/var' [15.00 GB] inherit ACTIVE '/dev/storage/mysql' [20.00 GB] inherit ACTIVE '/dev/storage/pgsql' [7.00 GB] inherit ACTIVE '/dev/storage/exim' [12.00 GB] inherit ACTIVE '/dev/storage/apache' [25.00 GB] inherit ACTIVE '/dev/storage/tmp' [2.00 GB] inherit ACTIVE '/dev/storage/backup' [450.00 GB] inherit ACTIVE '/dev/storage/log' [15.00 GB] inherit

Any idea of what is wrong?
Thanks!
_______________________________________________
Ataraid-list mailing list
Ataraid-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list
Phillip Susi | 12 Nov 20:16 2012

PDC arrays > 2 TB and non 512 byte dm sector size


It appears that PDC arrays > 2 TB pretend they have > 512 byte sector
sizes.  I'm trying to figure out how to patch dmraid to support this
but I'm not sure how to tell device-mapper to use a different sector
size.  Is this possible?

Petr Uzel | 2 Nov 11:25 2012
Picon

Question about SCSI serial number retrieval algorithm

Hi,

I have a question about algorithm used in dmraid to retrieve the
serial number from the scsi device:

lib/device/scsi.c:

 77 /*
 78  * Retrieve SCSI serial number.
 79  */
 80 #define MAX_RESPONSE_LEN        255
 81 int
 82 get_scsi_serial(struct lib_context *lc, int fd, struct dev_info *di,
 83                 enum ioctl_type type)
 84 {
 85         int ret = 0;
 86         size_t actual_len;
 87         unsigned char *response;
 88         /*
 89          * Define ioctl function and offset into response buffer of serial
 90          * string length field (serial string follows length field immediately)
 91          */
 92         struct {
 93                 int (*ioctl_func) (int, unsigned char *, size_t);
 94                 unsigned int start;
 95         } param[] = {
 96                 { sg_inquiry, 3},
 97                 { old_inquiry, 11},
 98         }, *p = (SG == type) ? param : param + 1;
 99
100         if (!(response = dbg_malloc(MAX_RESPONSE_LEN)))
101                 return 0;
102
103         actual_len = p->start + 1;
104         if ((ret = (p->ioctl_func(fd, response, actual_len)))) {
105                 size_t serial_len = (size_t) response[p->start];
106
107                 if (serial_len > actual_len) {
108                         actual_len += serial_len;
109                         ret = p->ioctl_func(fd, response, actual_len);
110                 }
111
112                 ret = ret &&
113                      (di->serial = dbg_strdup(remove_white_space (lc, (char *) &response[p->start + 1], serial_len)));
114         }

If type == SG, this function uses two SG_IO ioctls() to retrieve the serial number.
First with response buffer length set to 4 (line 104), which is just enough to get the serial
number length, which is later used to set the length of buffer for the second ioctl() (line 109).

Why is this? Why not use sufficiently long buffer (MAX_RESPONSE_LEN) right with the first ioctl()?

I'm asking this because I've encountered a device which requires the buffer to be long
enough to store the serial number, otherwise the SCSI inquiry command timeouts [*]. If this
happens, not only that it gets stuck for some time, but also the response buffer from the first
ioctl contains all zeros, so serial_len on line 105 is set to 0 and condition on line
107 is false -> second ioctl() is not executed...

[*] I know this is likely a bug outside dmraid.

I'd really appreciate if someone could shed some light into why it is done this way.

Thanks in advance,

Petr

--
Petr Uzel
IRC: ptr_uzl  <at>  freenode
_______________________________________________
Ataraid-list mailing list
Ataraid-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list
Mark-Willem Jansen | 19 Jul 16:30 2012
Picon

RE: Picking up development of dmraid

<!-- .hmmessage P { margin:0px; padding:0px } body.hmmessage { font-size: 10pt; font-family:Tahoma } -->
Hi Bryn,

Thank for the comments. The complete picture is slowly evolving.

> > dmraid. So it would be a good idea to remove the partitioning
> > support from dmraid. This will mean the package maintainer will
> > need to make dmraid dependent on kpartx for it to work.
>
> It already does in most (all?) distributions that ship it.

Probably Debian is legging behind here, as dmraid is unmaintained AFAIK.

> > One remark on this: I found that on Debian to make kpartx work
> > with dmraid during boot, one needs to make some changes to the
> > multipath-tools packages.
>
> What were the changes? The kpartx command is part of multipath-tools
> and although it's common to have it in a separate sub-package (all
> current Red Hat and Fedora distros do this) they are part of the same
> project upstream.

On Debain there is a package called multipath-tools-boot, which will add multipath, kpartx, and dmsetup to the initramfs. But I did not liked what multipath was doing to the /dev/mapper directory. So I mimicked ubuntu and made a separate package kpartx-boot. So when I come to think of it, maybe it worked out of the debian-box, apart from some warnings during boot.

> > On a side note: Why does mdadm support MBR and GPT?
>
> Not sure what you're asking here? The kernel MD driver creates
> partitionable devices so you can use any of the label formats that are
> enabled in the kernel you're running (although really, MBR and GPT are
> the only ones that make sense for most systems today).

I do not know the finer detail of mdadm, yet. But I saw super-mbr.c and super-gpt.c and and draw the conclusion, taken how dmraid handles mbr, that these were codes to parse mbt and gpt partition tables.

> I think adding new format handlers to MD is a much better idea; the
> dominant formats backed by major OEMs are already using it so if
> there's interest in the less commonly used formats I think they would
> see much better maintenance and continued development in an active
> project like mdadm than they would in a revived dmraid.

So it would be time that someone(probably me) starts adding the Promise formats used by the AMD chip-sets.

> > Just one last question I never really got an answer to. Can one
> > use mdadm on a dual boot system(MS and Linux) were the RAID
> > partitions are shared? In other words will mdadm leave the metadata
> > on the disks unchanged or in a state the the MS drivers can still
> > recognize the RAID.
>
> Assuming that MD supports the format handler you need: yes.

That is nice to hear.

> I think the time would be better spent learning or contributing to MD
> and mdadm development and adding support for other format handlers
> that have users wanting native Linux support.

Then it is time for me to start reading into mdadm.

Kind regards,

Mark-Willem
_______________________________________________
Ataraid-list mailing list
Ataraid-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list
Mark-Willem Jansen | 18 Jul 10:20 2012
Picon

Picking up development of dmraid

Dear dmraid developers,

Sometime in this mail-list it was said that the program dmraid was in maintaining mode and not further developed anymore. In the meantime the dm-developement team has put out new dm-target, which can be used by the tool.

I would like to fork the latest RC and put on github, to continue developing the tool. I will give it a slightly new name, so people will not confuse it with the original. My plan is to add the support for new dm-targets and also implement more partition tables, starting with GPT.

I am not really good at generating new names, but here are some ideas.

dmraid-fbmw (forked by Mark-Willem)
dmraid-fu (follow-up)
dmraid-ext (extended version)

So my question which name you think is a good one for the forked?

And who can I connect if I have some questions about the tool.

Greetings,

Mark-Willem Jansen

_______________________________________________
Ataraid-list mailing list
Ataraid-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list
Mark-Willem Jansen | 3 May 23:12 2012
Picon

Changing from dm-raid45.ko to dm-raid.ko

Dear md/dm developers,

As I already pointed out on the ataraid-list, I have made a small patch for dmraid, so it will use the dm-raid target in state of the dm-raid45 target to handle raid4 and riad5 setups. This patch is added to this e-mail. To put it in context I use dmraid to detect my fakeraid, which is shared with a Windows OS.

There were some things I could not figure out and would like to ask three questions regarding the arguments passed to the module.

- First a more general question does it look okay to you what I have implemented?

- Second what to do with the offset variable that is given by the metadata on the disk? On the other dmraid related modules the disk information is passed like [dev][offset]. With the dm-raid module it changed to [meta-dev][data-dev]. In the patch I ignore the meta-dev and just pass "- path_to_dev" to the module. This will work as the offset given by the metadata on my disks are equal to zero, the same value that is automatically set by the module. What does one have to do if the metadata on the disk says that the offset is not equal to zero?

- Last I would like to build up the argument string more generally. Like concatenate the argument strings depending on some if statements, like

if(need_sync)
   num_arg += 2;
   arguments = arguments + sprintf("rebuild %d", rebuild_drive.data.i32);
fi

And then pass the final string using

p_fmt(lc, table, "0 %U %s %s %u %s", sectors, dm_type, raid_type, num_arg, arguments).

This will make the code easier to read and quicker to hack/change/code.

Thanks,

Mark-Willem Jansen
P.S.: The patch is a modified version of the one I send to the ataraid-list some weeks ago.
_______________________________________________
Ataraid-list mailing list
Ataraid-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list
Phillip Susi | 2 May 05:16 2012

dmraid incompatible with multipath-tools?


A user recently filed this bug report against ubuntu 12.04:

https://bugs.launchpad.net/ubuntu/+source/dmraid/+bug/992975

I believe this is the result of my patch fixing the testing support, and testing being enabled by default. 
With testing enabled, it looks like dmraid is finding the physical disks both on the normal scsi devnode,
and again on the dm devnode created by multipath-tools.

Why does multipath-tools create a dm mapping for each physical disk by default?  It seems like this is likely
to cause other problems as well.  I suppose that configuring dmraid with --disable-testing would resolve
this issue ( and it probably should be disabled by default if it doesn't play well with multipath-tools ),
but I'd like to understand multipath-tools better first and try to find a better solution.

Mark-Willem Jansen | 13 Apr 01:23 2012
Picon

RE: Howto: implement AMD SB9xx RAID5 support in dmraid

Hi,

Been playing with the patches you gave me. And I finally got the raid up and running, using the shipped dm-raid.ko module in the 3.2 kernel.

Lets go through the steps.

I have applied the dmraid_pdc_raid5.patch, this caused dmraid to produce a new error related to the missing dm-raid45 module. Before activating a new raid set  dmraid checks if a dm-target has been registered with device-mapper. This can be changed through a struct in metadata.c. Doing this accordingly only left me with the error of raid array not activated. Going through the dmesg I found that dmraid was giving a wrong raid type to the dm-raid module. Digging deeper I wound that the arguments given to dm-raid45 and dm-raid have a different structure. So I have changed the arguments structure send to the module accordingly.

$ dmraid -ay -t
pdc_ciihdaafgf: 0 1953124864 raid raid5_la 2 128 nosync 3 - /dev/sdb - /dev/sdc - /dev/sdd

this used to be something like (I forgot some numbers)
$ dmraid -ay -t
pdc_ciihdaafgf: 0 1953124864 raid core 2 132016 nosync raid5_la 1 128 3 -1 /dev/sdb 0 /dev/sdc 0 /dev/sdd 0

The patch has been attached. (see that I have made some typo's in naming the patch.)

Now I can activate the raid and by using kpartx I can also mount the partitions on the raid. Whoot.

Unfortunately the fix was a bit dirty, could be that I have broken dmraid for the other raid types. Also I am not sure if you need to send the region_size to the dm-raid module.

Regards,

Mark-Willem

Date: Tue, 3 Apr 2012 11:13:20 +0400
From: astarta <at> rat.ru
To: markwillem <at> hotmail.com
CC: ataraid-list <at> redhat.com
Subject: Re: Howto: implement AMD SB9xx RAID5 support in dmraid

Hello,

I do have dm-raid45 patch for 3.2.
I do not remember where it was taken from, but it compiles with 3.2 :-)


On 04/03/2012 11:13 AM, Mark-Willem Jansen wrote:
.ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Tahoma;}
Hello,

Later this day I will apply the patch. But patching the kernel will be more cumbersome. The
present kernel running om my system is 3.2.0 and the patches found on the web are for
older kernels. But maybe the module dm-raid.ko included in the kernel can be helpful.

Regards,

Mark-Willem

> Date: Mon, 2 Apr 2012 17:42:12 +0400
> From: astarta <at> rat.ru
> To: markwillem <at> hotmail.com
> CC: psusi <at> ubuntu.com
> Subject: Re: Howto: implement AMD SB9xx RAID5 support in dmraid
>
> hello,
>
> You may try the attached patch to support RAID5 in pdc dmraid format. It
> works OK for me.
> Be sure to patch the kernel itself to support dm-raid45 target.
>
>
> On 04/02/2012 02:59 AM, Phillip Susi wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 04/01/2012 04:21 PM, Mark-Willem Jansen wrote:
> >> ERROR: pdc: zero sectors on /dev/sdd
> >> ERROR: pdc: setting up RAID device /dev/sdd
> > It looks like sectors() in pdc.c is missing the case for computing the size of a RAID5. For that matter, there appears to be no #define for PDC_T_RAID5, so you will need to add one and add it to the mapping table in type() and fix sectors() to handle it and probably a few other things.
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iQEcBAEBAgAGBQJPeN2yAAoJEJrBOlT6nu75NFQIANRt6f4STTvdEV+lYbsT8OL3
> > l22ZRVt9ReIAu7CJzRjx0yfaYAUo6Zy8fwzOjt9eF4fPYVQvnn53SYQu/qtyv2DZ
> > rDyv7owpxwcqQsZIYvBzQvWjEVT2s6VJrVtOVnZ2G1awa1SwIoc9LPnmouOeKhQG
> > auYL+O1UqfQEroJDsnOkZ8srrgc/m2zN3AxID4ps0FymQyNgy2s+HhBlsI4LeUNK
> > GimqJMwfbvaMlk0u8botcm2aMwogq+ap1GhJYddnRMluS6U4UJnS7NYrZYtww/1m
> > 3WJWkX9hsYxo+QBA0qassg3zc/efzkC8pBBvDo7FLNGcXs2txi7dXmNXLferwFo=
> > =o0zP
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Ataraid-list mailing list
> > Ataraid-list <at> redhat.com
> > https://www.redhat.com/mailman/listinfo/ataraid-list
>
>
> --
> С уважением,
> Astarta
> Администратор Форума "Крысиный Бум"
> http://rat.ru/forum/index.php
>
> “The Linux philosophy is 'Laugh in the face of danger'.
> Oops. Wrong One. 'Do it yourself'. Yes, that's it.”
> (c) Linus Torvalds.
>


-- С уважением, Astarta Администратор Форума "Крысиный Бум" http://rat.ru/forum/index.php “The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it.” (c) Linus Torvalds.
_______________________________________________
Ataraid-list mailing list
Ataraid-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list
Mark-Willem Jansen | 3 Apr 09:47 2012
Picon

RE: Howto: implement AMD SB9xx RAID5 support in dmraid

Hi,

It keeps getting better. Looks like I am in for a kernel compilation. Or at least the changed modules.

Thanks and I will keep you posted.

--
Mark-Willem

Date: Tue, 3 Apr 2012 11:13:20 +0400
From: astarta <at> rat.ru
To: markwillem <at> hotmail.com
CC: ataraid-list <at> redhat.com
Subject: Re: Howto: implement AMD SB9xx RAID5 support in dmraid

Hello,

I do have dm-raid45 patch for 3.2.
I do not remember where it was taken from, but it compiles with 3.2 :-)


On 04/03/2012 11:13 AM, Mark-Willem Jansen wrote:
.ExternalClass .ecxhmmessage P {padding:0px;} .ExternalClass body.ecxhmmessage {font-size:10pt;font-family:Tahoma;}
Hello,

Later this day I will apply the patch. But patching the kernel will be more cumbersome. The
present kernel running om my system is 3.2.0 and the patches found on the web are for
older kernels. But maybe the module dm-raid.ko included in the kernel can be helpful.

Regards,

Mark-Willem

> Date: Mon, 2 Apr 2012 17:42:12 +0400
> From: astarta <at> rat.ru
> To: markwillem <at> hotmail.com
> CC: psusi <at> ubuntu.com
> Subject: Re: Howto: implement AMD SB9xx RAID5 support in dmraid
>
> hello,
>
> You may try the attached patch to support RAID5 in pdc dmraid format. It
> works OK for me.
> Be sure to patch the kernel itself to support dm-raid45 target.
>
>
> On 04/02/2012 02:59 AM, Phillip Susi wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 04/01/2012 04:21 PM, Mark-Willem Jansen wrote:
> >> ERROR: pdc: zero sectors on /dev/sdd
> >> ERROR: pdc: setting up RAID device /dev/sdd
> > It looks like sectors() in pdc.c is missing the case for computing the size of a RAID5. For that matter, there appears to be no #define for PDC_T_RAID5, so you will need to add one and add it to the mapping table in type() and fix sectors() to handle it and probably a few other things.
> >
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.11 (GNU/Linux)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> >
> > iQEcBAEBAgAGBQJPeN2yAAoJEJrBOlT6nu75NFQIANRt6f4STTvdEV+lYbsT8OL3
> > l22ZRVt9ReIAu7CJzRjx0yfaYAUo6Zy8fwzOjt9eF4fPYVQvnn53SYQu/qtyv2DZ
> > rDyv7owpxwcqQsZIYvBzQvWjEVT2s6VJrVtOVnZ2G1awa1SwIoc9LPnmouOeKhQG
> > auYL+O1UqfQEroJDsnOkZ8srrgc/m2zN3AxID4ps0FymQyNgy2s+HhBlsI4LeUNK
> > GimqJMwfbvaMlk0u8botcm2aMwogq+ap1GhJYddnRMluS6U4UJnS7NYrZYtww/1m
> > 3WJWkX9hsYxo+QBA0qassg3zc/efzkC8pBBvDo7FLNGcXs2txi7dXmNXLferwFo=
> > =o0zP
> > -----END PGP SIGNATURE-----
> >
> > _______________________________________________
> > Ataraid-list mailing list
> > Ataraid-list <at> redhat.com
> > https://www.redhat.com/mailman/listinfo/ataraid-list
>
>
> --
> С уважением,
> Astarta
> Администратор Форума "Крысиный Бум"
> http://rat.ru/forum/index.php
>
> “The Linux philosophy is 'Laugh in the face of danger'.
> Oops. Wrong One. 'Do it yourself'. Yes, that's it.”
> (c) Linus Torvalds.
>


-- С уважением, Astarta Администратор Форума "Крысиный Бум" http://rat.ru/forum/index.php “The Linux philosophy is 'Laugh in the face of danger'. Oops. Wrong One. 'Do it yourself'. Yes, that's it.” (c) Linus Torvalds.
_______________________________________________
Ataraid-list mailing list
Ataraid-list <at> redhat.com
https://www.redhat.com/mailman/listinfo/ataraid-list

Gmane