XigmaNAS

Hi all,
I have a machine with an Adaptec 51245, 5 HDD configured as a RAID 6 array.
Installed Nas4Free 11.0.0.4.4195 and it's showing individual disks not the array
I'm missing something?
The driver documentation(!) https://www.freebsd.org/cgi/man.cgi?que ... ormat=html
says that I have to see a /dev/aacd0 disk.

Edit: Added a JBOD disk but also this is showing as /dev/pass4 and is read only!

Edit: It seems that a driver compiled in side the Kernel is working bad... How to disable it?

Thanks
N

Here the dmesg log:

aac0: <Adaptec RAID 51245> mem 0xfd000000-0xfd1fffff irq 16 at device 0.0 on pci5
aac0: Enabling 64-bit address support
aac0: Enable Raw I/O
aac0: Enable 64-bit array
aac0: New comm. interface enabled
aac0: Adaptec 51245, aac driver 2.1.9-1
aacp0 on aac0
aacp1 on aac0
aacp2 on aac0
(probe17:aacp2:0:0:0): REPORT LUNS. CDB: a0 00 00 00 00 00 00 00 00 10 00 00
(probe17:aacp2:0:0:0): CAM status: CCB request completed with an error
(probe17:aacp2:0:0:0): Retrying command
...
(probe17:aacp2:0:0:0): Error 5, Retries exhausted
...
ses0 at aacp2 bus 0 scbus35 target 0 lun 0
ses1 at aacp2 bus 0 scbus35 target 1 lun 0
ses2 at aacp2 bus 0 scbus35 target 2 lun 0
pass2 at aacp0 bus 0 scbus33 target 2 lun 0
pass3 at aacp0 bus 0 scbus33 target 3 lun 0
pass4 at aacp0 bus 0 scbus33 target 6 lun 0
pass5 at aacp0 bus 0 scbus33 target 7 lun 0
pass6 at aacp0 bus 0 scbus33 target 8 lun 0
pass7 at aacp0 bus 0 scbus33 target 10 lun 0
pass8 at aacp0 bus 0 scbus33 target 11 lun 0

I removed the redundant lines.
Actually there are 7 disks: 1 JBOD and 1 array RAID 6 of 6 disks.
The driver doesn't create the /dev/aacd# nodes.
The /dev/pass# are readonly (but Nas4Free tries to format, etc).

I have tried to disable the driver included in the kernel but without success, with "hint.aac.0.disable=1" in loader.conf (of course using the browser interface).

Any help??
Thanks

Try to clear any configuration on the raid controller bios.
Leave the disks unconfigured.
What does n4f see in this case?

ChriZathens wrote: ↑

18 May 2017 22:02

Try to clear any configuration on the raid controller bios.

Useless! It's a new machine built from start. This a comment like "try to format all"...

ChriZathens wrote: ↑

18 May 2017 22:02

Leave the disks unconfigured.

Not possible: the controller doesn't exposes unconfigured disk, like many other raid controller.

The problem is in the FreeBSD driver, it seems because a modification introduced in 10.1, still investigating, will report!
Thanks anyway
Nicola

Ok, then (kinda expected that TBH)
Back to the jbod configuration, then.
When you say the disks are read only...
Have you tried formatting the disks via nf4 webgui and it fails to do so?
(It is not very clear from your previous post. When you say nf4 tries to format, does it succed, or you mean that you simply have this option?)

ChriZathens wrote: ↑

18 May 2017 23:15

Ok, then (kinda expected that TBH)
Back to the jbod configuration, then.
When you say the disks are read only...

This is the NORMAL, EXPECTED behaviour of /dev/pass# devices. They are not useable like disks, are good for eg. SMART or advanced config.

ChriZathens wrote: ↑

18 May 2017 23:15

Have you tried formatting the disks via nf4 webgui and it fails to do so?
(It is not very clear from your previous post. When you say nf4 tries to format, does it succed, or you mean that you simply have this option?)

I said this because this is a BUG of Nas4Free: these devices are not drives and must not be shown between drives.

I lost you here...
In the past I remember having disks shown as /dev/pass0, /dev/pass1 etc
They were the actual disks. How they appear depends on the controller.
Can you post the result of camcontrol devlist? (Having them as jbod)

ChriZathens wrote: ↑

18 May 2017 23:47

I lost you here...
In the past I remember having disks shown as /dev/pass0, /dev/pass1 etc
They were the actual disks. How they appear depends on the controller.
Can you post the result of camcontrol devlist?

The /dev/pass# devices are character devices, not disks.
For each disk exists 1 (one) pass device. Some disk has also a /dev/da# device (or similar).
https://www.freebsd.org/cgi/man.cgi?que ... &sektion=4

The problem here is that the driver decides to not create the /dev/aacd# node for the drives (or arrays).
The cause seems to be in aac/aac_cam.c. Tomorrow will try to patch.

Can you please first post the result of camcontrol devlist and then we can jump into conclusions?
P.S.: Don't focus on the failed identification of the array.
Your goal is to see individual disks here.

ChriZathens wrote: ↑

19 May 2017 00:01

Can you please first post the result of camcontrol devlist and then we can jump into conclusions?
P.S.: Don't focus on the failed identification of the array.
Your goal is to see individual disks here.

I can post the (useless) devlist only tomorrow.
You had jumped to conclusion that my goal is individual disk! WRONG! (*)
It's a RAID controller and I want to have my RAID 6 array
I connected also a JBOD but only for test.

My (temporary) conclusion is determined from many tens of pages read, forums, sources, tests and the experience of 30 years.
Of course I often make mistakes

(*) Note: debating my goal is OT!

ZFS wants to have total control of the disks and it wants your controller to act as an HBA.
The point here is not what you want to do. It is what you should do.
You want to pass a Raid6 array to ZFS. What you should do, is pass individual disks and then use nf4 to create a RaidZ2 array with those disks. Otherwise you may have ZFS and the controller battling each other, which may lead to abysmal performance and/or data destruction.

Having said that, if you want to pass a Raid6 array to nf4, it certainly is your right to do so. Since you have a 30 year experience, you obviously know what you are doing.
Unfortunately I'm on mobile right now, so can't provide much help. Perhaps you should look into loading the driver using loader.conf.
For LSI raid controllers IIRC, you needed to put something like mfi_load=yes in loader.conf.
Maybe you need to do something similar with the Adaptec driver.
Look towards this direction and/or wait for someone else who may have an Adaptec controller to provide any other ideas
Have a pleasant night.

ChriZathens wrote: ↑

19 May 2017 00:57

ZFS wants to have total control of the disks and it wants your controller to act as an HBA.
The point here is not what you want to do. It is what you should do.

STOP here.
ZFS is OT here.
What I want or my goal is OT.
The problem here is the bugged driver: aac.ko.
Here the output of "camcontrol devlist":

<NECVMWar VMware SATA CD00 1.00> at scbus2 target 0 lun 0 (pass0,cd0)
<VMware Virtual disk 2.0> at scbus32 target 0 lun 0 (pass1,da0)
<Hitachi HDS722020ALA330 JKAO> at scbus33 target 2 lun 0 (pass2)
<Hitachi HDS722020ALA330 JKAO> at scbus33 target 3 lun 0 (pass3)
<Hitachi HDS722020ALA330 JKAO> at scbus33 target 6 lun 0 (pass4)
<Hitachi HDS722020ALA330 JKAO> at scbus33 target 7 lun 0 (pass5)
< HDS722525VLSA80 V36O> at scbus33 target 8 lun 0 (pass6)
<Hitachi HDS722020ALA330 JKAO> at scbus33 target 10 lun 0 (pass7)
<Hitachi HDS722020ALA330 JKAO> at scbus33 target 11 lun 0 (pass8)
<ADAPTEC Virtual SGPIO 0 0001> at scbus35 target 0 lun 0 (pass9,ses0)
<ADAPTEC Virtual SGPIO 1 0001> at scbus35 target 1 lun 0 (pass10,ses1)
<ADAPTEC Virtual SGPIO 2 0001> at scbus35 target 2 lun 0 (pass11,ses2)

PS: in my system ZFS is disabled!

you are not alone: https://forums.freebsd.org/threads/60736

I compiled the Adaptec driver for FreeBSD 8, no go.
I contacted Adaptec support: useless.
The problem is somewhere between the cam driver and the aac driver.
Giving up...

Thanks for your help