Recognising an external raid config

[UbuntuBantu]

Hi

I have a HighPoint RocketRaid 2322 RAID controller installed in my Asus p5wdg2ws pro. Attached to the 2322 controller via an Infiniband cable is a Highpoint X4 External SATA 4-bay enclosure. The enclosure contains 4x400GB hdd's curretly configured in JBOD (temporarily only to help me move data between machines, following which the drives will be reinitialized as a RAID 5 config).

I have previously successfully compiled and installed the drivers under Ubuntu 6.06 (Dapper) and proceeded to use the drives. I've since upgraded to Ubuntu 6.1 (Edgy) and recompiled and successfully installed the drivers (confirmed via lsmod):

lsmod | grep rr
rr232x 176802 1
scsi_mod 144648 9 bp2,sr_mod,rr232x,sg,aic7xxx,scsi_transport_spi,sd _mod,ahci,libata

Whilst everything seems to be in place the X4 no longer seems to be detected. Under Dapper it showed up as '/dev/sde', whereas /dev/sde isn't detected in Edgy. I know the device and card are not faulty - (can see it on another PC using the very same controller w/windoze installed)

dmesg |grep rr232 shows the following:
[17179601.204000] rr232x: module license 'Proprietary' taints kernel.
[17179601.208000] rr232x:1: RocketRAID 232x controller driver v1.03 (Nov 11 2006 12:08:54)
[17179601.208000] Modules linked in: rr232x snd_timer usbhid agpgart sg skge i2c_core snd sky2 parport_pc parport evdev soundcore snd_page_alloc shpchp pci_hotplug psmouse serio_raw pcspkr floppy ext3 jbd ohci1394 ieee1394 ehci_hcd uhci_hcd usbcore ide_generic aic7xxx scsi_transport_spi sata_promise sd_mod ahci libata scsi_mod ide_cd cdrom piix generic thermal processor fan fbcon tileblit font bitblit softcursor vesafb capability commoncap
[17179601.208000] EIP is at f8e22123f+0x18/0x50 [rr232x]
[17179601.208000] <f8b39f04> hpt_detect+0x54/0x780 [rr232x] <c011ba7e> try_to_wake_up+0x6e/0x3d0
[17179601.208000] <f89bb041> init_this_scsi_driver+0x41/0x102 [rr232x] <c012f880> blocking_notifier_call_chain+0x30/0x60
[17179601.208000] EIP: [<f8b3be38>] f8e22123f+0x18/0x50 [rr232x] SS:ESP 0068:f7f19e50


Any ideas as to how to go about diagnosing and resolving the problem?

Thx

[dkeav]

udev rules may have changed and its being assigned a different name, /dev/sd[a-z] or elsewhere, check your dmesg further down or so to try to find where udev has assigned it, or look around in /dev or /sys, otherwise you should probably have some more substantial errors in dmesg//var/log/messages

[UbuntuBantu]

udev rules may have changed and its being assigned a different name, /dev/sd[a-z] or elsewhere, check your dmesg further down or so to try to find where udev has assigned it, or look around in /dev or /sys, otherwise you should probably have some more substantial errors in dmesg//var/log/messages

Looks like you're right about the errors. The tough part is going to be figuring out the cause given the driver compiled, installed and worked under Dapper. Extract from /var/log/dmesg:

[17179601.540000] rr232x: module license 'Proprietary' taints kernel.
[17179601.540000] rr232x:0: RocketRAID 232x controller driver v1.03 (Nov 14 2006 08:19:42)
[17179601.540000] BUG: unable to handle kernel paging request at virtual address 6788fd68
[17179601.540000] printing eip:
[17179601.540000] f8bb6e38
[17179601.540000] *pde = 00000000
[17179601.540000] Oops: 0000 [#1]
[17179601.540000] SMP
[17179601.540000] Modules linked in: rr232x snd_hda_intel snd_hda_codec i2c_core sk98lin usbhid snd_pcm_oss snd_mixer_oss skge sky2 sg psmouse parport_pc snd_pcm parport evdev serio_raw pcspkr shpchp pci_hotplug snd_timer floppy snd soundcore snd_page_alloc ext3 jbd ohci1394 ieee1394 uhci_hcd ehci_hcd usbcore ide_generic aic7xxx scsi_transport_spi sata_promise sd_mod ahci libata scsi_mod ide_cd cdrom piix generic thermal processor fan fbcon tileblit font bitblit softcursor vesafb capability commoncap
[17179601.540000] CPU: 0
[17179601.540000] EIP: 0060:[<f8bb6e38>] Tainted: P VLI
[17179601.540000] EFLAGS: 00010203 (2.6.17-10-generic #2)
[17179601.540000] EIP is at f8e22123f+0x18/0x50 [rr232x]
[17179601.540000] eax: 00000000 ebx: f8bdd680 ecx: f8bdd140 edx: 6ecb2bc8
[17179601.540000] esi: f8bdd680 edi: ffffffed ebp: 000005f0 esp: f7f81e50
[17179601.540000] ds: 007b es: 007b ss: 0068
[17179601.540000] Process modprobe (pid: 3258, threadinfo=f7f80000 task=f782e030)
[17179601.540000] Stack: f8bb4f04 f8bd5bca f8bdd140 f8bdd162 c043b1e0 00000296 c011ba7e f8bdd080
[17179601.540000] f8bdd1e0 c011d497 00000000 00000000 00000000 00000000 00000296 00000002
[17179601.540000] c0145fa6 00000000 c200d5a0 c02f427a dfe16030 dfe16038 00000000 f8bdd680
[17179601.540000] Call Trace:
[17179601.540000] <f8bb4f04> hpt_detect+0x54/0x780 [rr232x] <c011ba7e> try_to_wake_up+0x6e/0x3d0
[17179601.540000] <c011d497> __cond_resched+0x17/0x30 <c0145fa6> __stop_machine_run+0x86/0xb0
[17179601.540000] <f89b1041> init_this_scsi_driver+0x41/0x102 [rr232x] <c012f880> blocking_notifier_call_chain+0x30/0x60
[17179601.540000] <c013cda8> sys_init_module+0x148/0x19c0 <c01e98a0> pci_bus_read_config_byte+0x0/0x80
[17179601.540000] <c0102fbb> sysenter_past_esp+0x54/0x79
[17179601.540000] Code: 5e e9 bd c2 ff ff 8d b6 00 00 00 00 8d bc 27 00 00 00 00 8b 54 24 04 31 c0 8b 4c 24 08 3b 15 c8 d1 bd f8 7d 32 8d 14 92 c1 e2 02 <66> 8b 82 a0 d1 bd f8 66 89 01 66 8b 82 a2 d1 bd f8 66 89 41 02
[17179601.540000] EIP: [<f8bb6e38>] f8e22123f+0x18/0x50 [rr232x] SS:ESP 0068:f7f81e50

[dkeav]

as usual, its a hardware issue, so that has nothing to do with the distro name ;)
and everything to do with the kernel, it appears there is a bug with that driver and the kernel version you are up to, i would imagine if you hang around the maintainer of the drivers site for awhile they will have a fix or an updated driver, probably in cvs/svn now or soon

[UbuntuBantu]

as usual, its a hardware issue, so that has nothing to do with the distro name ;)
and everything to do with the kernel, it appears there is a bug with that driver and the kernel version you are up to, i would imagine if you hang around the maintainer of the drivers site for awhile they will have a fix or an updated driver, probably in cvs/svn now or soon

You are correct in that it is most definitely a driver issue. I reverted to Dapper Drake (2.6.15-27-386), recompiled the driver and voila. I'll have to stay with Dapper until the source drivers are updated.

On another note, now that everything is up and running again I have another related question. The original JBOD on the X4 comprised 2 disks partitioned and formatted ext3. I subsequently added 2 additional drives ie now have 4 identical drives installed. disks-admin shows a 745gb partition and 745gb unpartitioned space. gparted (GParted 0.1) on the other hand shows the JBOD as -571397.65MB (see screenshot) and shows a partition of 745GB and no unused space. End result - I cannot add additonal partitions or increase the size of the existing partition. Does gparted have a size limitation under 2tb?

[dkeav]

dont trust gparted for one, but more specifically the only real way to ensure your data integrity here, is to one make sure you have backups and probably destroy the partition, and create a new one, though for future refrence cases such as these is where LVM comes in handy

[UbuntuBantu]

dont trust gparted for one, but more specifically the only real way to ensure your data integrity here, is to one make sure you have backups and probably destroy the partition, and create a new one, though for future refrence cases such as these is where LVM comes in handy

LOL, the irony here is that this initial 745GB partiton is a recovery job from a failed NTFS spanned partition. 100% recovery with no data loss. Took around 20 hours but is an automated recovery process. I still have the failed span untouched so could rerun the recovery if really necessary. The idea was to recover all the data to the X4 span, back it up and then go full-blown raid, unfortunately it seems NTFS is a little more efficient so I have yet to recover additional folders which there isn't enough space for, which is why I added the two additional drives. It's easy to see why people can grow to hate computers!

[dkeav]

hate is a strong word, more they learn to give up and do what is required of them, mostly the planning ahead part especially when large amounts of invaluable data is at risk

its one of those buzz words, "disaster recovery plan"

[UbuntuBantu]

its one of those buzz words, "disaster recovery plan"

My storage needs have grown over time (primarily flac encoded audio played through a Squeezebox, and family photos & video), gradually spreading from one hard drive to another, to another etc. without much thought given to backup until I realised that I never want to have to rerip and re-encode all my cd's (>1100), was tired of telling slimserver to look all over the place across two pc's for my music library and figured that losing all our photos and video was probably not a good idea. My end-game solution is a Highpoint RocketRaid 2322 controller) with two Hightpoint X4's attached. The idea was copy all data to the RAID config, back it up using my LTO2 drive and that would be the end of it - nice and simple.

Unfortunately, things are never as simple as they seem because I didn't count on a windows deciding to declare a jbod volume corrupt before I could make my raid volume. The 2nd thing I didnt count on was ext3 handling less data than NTFS, hence my inability to recover the remaining data - I've nowhere to put it, unless of course I could actually expand the existing JBOD in the X4 to which I've recovered the content of the windows jbod. So here I sit with 750GB of storage in the X4 unused and unuseable unless I kill the whole thing and create a raid array out of it, hoping that the windows jbod is just as recoverable now as it was then (the drives themselves are fine). The X4 and LTO are supposed to be my DRP!

[UbuntuBantu]

...for future refrence cases such as these is where LVM comes in handy

Care to elaborate, I've never used LVM? Is it beneficial over creating a RAID5 through the controller BIOS?

[dkeav]

well for one, your JBOD wont work very well when you create that raid5 array, creating the array is a destructive process when it create the parity blocks so all data on the drives will be destroyed, you need your raid array setup before you start your backup, unless you have somewhere else to store you data while the array is created then put it back onto those drives

LVM is useful from the filesystem standpoint, although some higher end filesystem can grow to fill out the rest of the unused space (JFS,XFS) for example, LVM provides a virtualized layer on top of that and provides that sort of functionality to older or more primitive filesystems like ext2/3

you are using a hardware raid though, so the array managment itsself kind of negates the need software level managment ie LVM, it would make more sense to create the raid array, and use a better filesystem example JFS, you would then be able to grow the array with more drives, and grow the filesystem with the array easily

main point being, if you put all your data on the drives as JBOD and then try to turn them into an array, you are going to lose your data

[UbuntuBantu]

main point being, if you put all your data on the drives as JBOD and then try to turn them into an array, you are going to lose your data

Appreciate that - the idea was to copy the data back to the repartitioned and reformatted source drives, then to create and populate the RAID5 config.