FreeNAS 11 dropped gmultipath array?

[cookiesowns]

So after migrating from FreeNAS 9.10 -> Corral, then back to 9.10 then to FreeNAS 11 it seems that FreeNAS has lost all gmultipath labels for our drives and it automatically imported our zpool from da0-da23... Which is great... but freenas thinks da24-da48 is all accessible.... so it concerns me.

Does anyone know the best non destructive way in order to get multipath back online?

Just for feedback, the array is on dual 9300-8i's connected in WIDEPORT on a SAS3(12gbps) dual expander backplane, which is 8 lanes per expander, with Dual Ported Seagate enterprise drives.

 

[dlavigne]

To clarify:

1. How did you go from Corral back to 9.10?

2. Was multipath displaying correctly in 9.10 prior to upgrading to 11?

3. Please post a screenshot of your Storage -> View Multipaths screen in 11.

 

[cookiesowns]

To clarify:

1. How did you go from Corral back to 9.10?

2. Was multipath displaying correctly in 9.10 prior to upgrading to 11?

3. Please post a screenshot of your Storage -> View Multipaths screen in 11.

I used a previous 9.10 snapshot that existed on the boot device and then just upgraded from 9.10 back to 11. I don't recall if multipath existed when we went back to 9.10 but it was there on Corral.

3. There is nothing there to view, as gmultipath doesn't detect any of the multi path labels and all drives are individually numbered now.

This is odd... in the view disks tab I see da24->da47, however the mounted devices on the array is from da0-da23....

Could there be a driver/firmware bug on our 9300-8i HBA's where they don't run in wideport mode?

 

[mav@]

Corral was using gmultipath without on-disk metadata and probably wiped them from disks. But I think gmultipath labels should be restored when you booted back into 9.10 ot 11.

 

[cookiesowns]

Corral was using gmultipath without on-disk metadata and probably wiped them from disks. But I think gmultipath labels should be restored when you booted back into 9.10 ot 11.

That makes sense... but that doesn't seem to be the case :(

 

[cookiesowns]

Any additional thoughts? Would it be possible to re-create the labels by hand without causing a destructive write on our dataset?