New member disk not showing up in "Create Volume" screen

[kimbecause]

When inserting two brand new, blank WD 2TB Caviar Green disks, neither showed up in the "Member Disks" area of the "Create Volume" dialogue. The disks did show up in the "Disk Replacement" Dialogue from the "View Disks" pane of any previously created Volume.

The disks were attached via SATA to a RocketRaid? 2300 4 port PCI-E to SATA adapter. Two ports were used for these disks. The other two ports were in use and operational. One of the other ports on this card happens to connect to an (almost) identical disk bought a few days earlier (another WD 2tb caviar green, but possibly from a different batch).

This is the output of "camcontrol devlist", which (I think) shows that this disk isn't there.

<WDC WD10EACS-00D6B0 09570115> at scbus0 target 0 lun 0 (ada0,pass0)
<WDC WD20EADS-00R6B0 01.00A01> at scbus0 target 1 lun 0 (ada1,pass1)
<WDC WD20EARS-00MVWB0 51.0AB51> at scbus0 target 2 lun 0 (ada2,pass2)
<WDC WD20EARX-00PASB0 51.0AB51> at scbus0 target 3 lun 0 (ada3,pass3)
<Port Multiplier 0325197b 000e> at scbus0 target 15 lun 0 (pass4,pmp0)
<WDC WD20EARX-00PASB0 51.0AB51> at scbus3 target 0 lun 0 (ada4,pass5)
<WDC WD20EARS-00MVWB0 51.0AB51> at scbus4 target 0 lun 0 (ada5,pass6)
<HPT DISK 0_0 4.00> at scbus5 target 0 lun 0 (da0,pass7)
<HPT DISK 0_1 4.00> at scbus5 target 1 lun 0 (da1,pass8)
<HPT DISK 0_2 4.00> at scbus5 target 2 lun 0 (da2,pass9)
<Verbatim STORE N GO 5.00> at scbus6 target 0 lun 0 (da3,pass10)

At first I figured that this may just be that the partition table hadn't been initialised, so I plugged it into a linux machine to create an MBR table with fdisk (but no partitions). This didn't work - the disk still failed to show.

Next I tried putting a single id 83 (linux) partition on the disk (for no particular reason; the partition wasn't formatted). The disk now showed up in the "Create Volume" dialogue.

A little after this I decided to delete the volume to add it to an existing pool, so I exported the volume and ticked to "Mark the disk as new". When the process was completed, the disk again failed to show in the "Create Volume" dialogue (even after reboot).

It was the second time of the disk not showing up that lead me to open the ticket to help out this great project. I can post any other information asked for; just tell me the commands to insert as I haven't been working with freenas long. I know that all I will have to do to fix this is to plug the drive into a different machine and make a single partition on it, but that isn't an ideal fix.

[mav]

If disk is not shown in camcontrol devlist output, it means it was not detected by drivers. It is definitely not related to partition tables.

I would start from looking on that RocketRaid? 2300 card. As soon as it is RAID, can't it be that it just doesn't expose disk that is not configured as part of any array?

[kimbecause]

I checked that early on in the process but the 2300 card was just in a JBOD configuration. I looked around for a setting that would indicate that the first two ports were displayed to the processor differently to the second two, but couldn't find any.

For my own sanity I rebooted and rechecked the sata controller bios. No disks are initialised for a raid array (or ever have been as far as I remember). All 4 disks attached to the controller are set up the same way, but those two didn't initially show up.

I have also redone the add a partition fix, and the drive now shows up again in the Create Volume dialogue, as well as "camcontrol devlist":

<WDC WD10EACS-00D6B0 09570115> at scbus0 target 0 lun 0 (ada0,pass0)
<WDC WD20EADS-00R6B0 01.00A01> at scbus0 target 1 lun 0 (ada1,pass1)
<WDC WD20EARS-00MVWB0 51.0AB51> at scbus0 target 2 lun 0 (ada2,pass2)
<WDC WD20EARX-00PASB0 51.0AB51> at scbus0 target 3 lun 0 (ada3,pass3)
<Port Multiplier 0325197b 000e> at scbus0 target 15 lun 0 (pass4,pmp0)
<WDC WD20EARX-00PASB0 51.0AB51> at scbus3 target 0 lun 0 (ada4,pass5)
<WDC WD20EARS-00MVWB0 51.0AB51> at scbus4 target 0 lun 0 (ada5,pass6)
<HPT DISK 0_0 4.00> at scbus5 target 0 lun 0 (da0,pass7)
<HPT DISK 0_1 4.00> at scbus5 target 1 lun 0 (da1,pass8)
<HPT DISK 0_2 4.00> at scbus5 target 2 lun 0 (da2,pass9)
<HPT DISK 0_3 4.00> at scbus5 target 3 lun 0 (da3,pass10)
<Verbatim STORE N GO 5.00> at scbus6 target 0 lun 0 (da4,pass11)

[ikke]

I added disk for replacing a similar one. Both are WD Caviar Black 2T disks. The new one does not appear into GUI disks list. I was able to read it through using dd as root, so it's showing ok for kernel and userland. But not in GUI. It's the ada1:

~# camcontrol devlist
<SAMSUNG HD103UJ 1AA01113> at scbus0 target 0 lun 0 (pass0,ada0)
<WDC WD2001FASS-00W2B0 05.01D05> at scbus1 target 0 lun 0 (pass1,ada1)
<WDC WD2001FASS-00W2B0 05.01D05> at scbus2 target 0 lun 0 (pass2,ada2)
<WDC WD2002FAEX-007BA0 05.01D05> at scbus3 target 0 lun 0 (pass3,ada3)
<WDC WD2002FAEX-007BA0 05.01D05> at scbus4 target 0 lun 0 (pass4,ada4)
<USB2.0 FlashDisk? 1100> at scbus6 target 0 lun 0 (pass5,da0)

Before adding the disk I dd'd it full of zeroes, so it was totally clean.

[ikke]

I found the disk in replace dialog. After starting raidz replace I can see the disk in disks list. Maybe I just misunderstood the GUI logic?

[william]

@ikke, are you using 8.0.4 as well? If so yes, View Disks does not show disks that are not part of a volume, as opposed of 8.2.x.

[ikke]

No, i'm using 8.2b3, sorry I forgot to mention that.

[ikke]

Additional bug related to this: Now that I got the new disk added, and safely removed the old one, the old disk is still visible on the list of disks as a ghost. It has all the edit button, powersave modes etc. listed as the other disks.

It was plugged out during power off. The cmdline reports the disks just right:

<SAMSUNG HD103UJ 1AA01113> at scbus0 target 0 lun 0 (pass0,ada0)
<WDC WD2001FASS-00W2B0 05.01D05> at scbus1 target 0 lun 0 (pass1,ada1)
<WDC WD2002FAEX-007BA0 05.01D05> at scbus3 target 0 lun 0 (pass2,ada2)
<WDC WD2002FAEX-007BA0 05.01D05> at scbus4 target 0 lun 0 (pass3,ada3)
<USB2.0 FlashDisk? 1100> at scbus6 target 0 lun 0 (pass4,da0)

This would likely be worth of it's own bugreport, but I add it here since it's part of the same problem/functionality.