OCE and GPT

[Lister]

I thought doing the OCE was an open and shut case, dare I to dream!
I thought Online Capacity Expansion– and RAID Level Migration (ORLM) were features accessible from 3Ware's HBA's BIOS. They were not. It turned out to be implemented in a software called 3DM2 (3Ware Disk Manager 2.) The latter marked the beginning of a new set of problems on FreeBSD-8.0. For reference, it's basically a daemon listening on port 888 and accessible from a browser and some tools to email admin alerts…etc. The package, though, was over 100MB installed from a 59MB sh script!

3Ware has specific S/W for FreeBSD-5.x, 6.x, 7.x, but not 8.0! I thought that may not be a problem after all, and tried to install it on 8.0. It insisted that I must install JRE beforehand. I tried to install diablo-jre16 from ports after update. That one, along the way installed so many other ports to satisfy its dependencies, including many X packages. I don't have X on any of my servers and I don't want it. Any way, installation succeeded in the end. But will it run?

/:602: /usr/sbin/3dm2
Fatal error 'kse_create() failed
' at line 441 in file /usr/src/lib/libpthread/thread/thr_kern.c (errno = 2)

After googling around, I found the exact same message, differing only in (errno.) It was regarding the same HBA as mine (3W 9650SE-xxxxx), yet on FreeBSD-7.0. The user was advised to add 'options KSE' to his kernel and recompile. He subsequently reported that this had solved his problem. I thought, that's promising. I added the option to my kernel and tried to build. Alas, I got "unknown option" error.

This is what my 7.1 knows about kse
/:1181: apropos kse
 kse(2)     - kernel support for user threads
Clearly it's very pertinent to the error message. But what does 8.0 know about it?
/:615: apropos kse
 Pod::Simple::LinkSection(3) - -- represent "section" attributes of L codes

Can anyone help with this?
Despite that the solution seems promising on 7.1, I can't risk losing a 7-years-worth library and must first experiment on the empty RAID on 8.0. Moving HBAs or disks between systems is not an option, for many strong reasons.


Note on where the extra space generated by OCE goes:
----------------------------------------------------
Although my logic had convinced me from the beginning that the extra space must go to the end of the RAID volume, I had to verify this. I did from forums and 3Ware documentation. Nonetheless, neither referenced multiple partitions, and they merely mentioned 'extending the disk' under Windows and 'resizing the partition and extending the filesystem' under others; and in either case 'or create a new partition.'  Logically, again, this should make no difference. This is predicated on the facts 
that HBA manufacturers tout OCE and ORLM as non-destructive (features), and also that hardware RAID HBAs must be OS/FS-indifferent.

The new capacity is reflected only after a complete rebuild of the array which occurs automatically after adding a drive to an existing array– both counts logical again. Additionally after the complete rebuild, an OS-dependent 'nudge' is needed to let it know of the change. However, the OS never needs to be rebooted unless it boots from the expanded RAID.

I thought I'd share this info with you.

Kind regards,
Hatem Kawashti