Bug 183406 - gpart label not accessible after reseating disk
Summary: gpart label not accessible after reseating disk
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.0-BETA2
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-28 15:50 UTC by Michael Gmelin
Modified: 2017-12-31 22:27 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Gmelin 2013-10-28 15:50:02 UTC 
When pulling a drive and reseating it in another slot, gpart doesn't show the drive's partition table anymore. When returning the drive to its original slot,  it shows up again just fine.

Controller is LSI SAS 2008 based 9211i-IT (mps(4) driver), running all attached drives as JBODs.

After reseating the drive to the correct slot, resilvering ZFS works fine as well. When it remains in the other slot, all kinds of terrible things start happening (including gpart segfaulting at some point). A reboot fixes all those issues.
 
camcontrol rescan all etc. won't help.

I'm not certain if this is due to the mps(4) driver (the drive always shows up as the same lun target, regardless of which slot) or an issue in gpart/geom, therefore I didn't specify in the synopsis.

Fix: 

na
How-To-Repeat: Hotswap a drive to a new bay.

Example procedure:
Show partition table (disk da1 is a spare):

[root@ ~]# gpart show -l
=>       34  585937433  da0  GPT  (279G)
         34        128    1  (null)  (64K)
        162   67108864    2  swapbay0  (32G)
   67109026  518828441    3  databay0  (247G)

=>       34  585937433  da1  GPT  (279G)
         34        128    1  (null)  (64K)
        162   67108864    2  swapbay2  (32G)
   67109026  518828441    3  databay2  (247G)

=>       34  585937433  da2  GPT  (279G)
         34        128    1  (null)  (64K)
        162   67108864    2  swapbay1  (32G)
   67109026  518828441    3  databay1  (247G)

=>       34  585937433  diskid/DISK-6SJ4HSQR0000N23132VX  GPT  (279G)
         34        128                                 1  (null)  (64K)
        162   67108864                                 2  swapbay2  (32G)
   67109026  518828441                                 3  databay2  (247G)

Pull drive da2:
Oct 28 15:11:34  kernel: da2 at mps0 bus 0 scbus7 target 0 lun 0
Oct 28 15:11:34  kernel: da2: <SEAGATE ST3300657SS 0008> s/n 6SJ2ZBP00000N2318ZSS detached
Oct 28 15:11:34  kernel: (da2:
Oct 28 15:11:34  kernel: mps0:0:0:
Oct 28 15:11:34  kernel: 0): Periph destroyed

Also disappeared from gpart (as expected):

[root@ ~]# gpart show -l
=>       34  585937433  da0  GPT  (279G)
         34        128    1  (null)  (64K)
        162   67108864    2  swapbay0  (32G)
   67109026  518828441    3  databay0  (247G)

=>       34  585937433  da1  GPT  (279G)
         34        128    1  (null)  (64K)
        162   67108864    2  swapbay2  (32G)
   67109026  518828441    3  databay2  (247G)

=>       34  585937433  diskid/DISK-6SJ4HSQR0000N23132VX  GPT  (279G)
         34        128                                 1  (null)  (64K)
        162   67108864                                 2  swapbay2  (32G)
   67109026  518828441                                 3  databay2  (247G)

Reseat drive in a different slot:
Oct 28 15:12:08  kernel: da2 at mps0 bus 0 scbus7 target 0 lun 0
Oct 28 15:12:08  kernel: da2: <SEAGATE ST3300657SS 0008> Fixed Direct Access SCSI-5 device 
Oct 28 15:12:08  kernel: da2: Serial Number 6SJ2ZBP00000N2318ZSS
Oct 28 15:12:08  kernel: da2: 600.000MB/s transfers
Oct 28 15:12:08  kernel: da2: Command Queueing enabled
Oct 28 15:12:08  kernel: da2: 286102MB (585937500 512 byte sectors: 255H 63S/T 36472C)

And give it some time to spin up... still, it won't show up in gpart

[root@ ~]# gpart show -l
=>       34  585937433  da0  GPT  (279G)
         34        128    1  (null)  (64K)
        162   67108864    2  swapbay0  (32G)
   67109026  518828441    3  databay0  (247G)

=>       34  585937433  da1  GPT  (279G)
         34        128    1  (null)  (64K)
        162   67108864    2  swapbay2  (32G)
   67109026  518828441    3  databay2  (247G)

=>       34  585937433  diskid/DISK-6SJ4HSQR0000N23132VX  GPT  (279G)
         34        128                                 1  (null)  (64K)
        162   67108864                                 2  swapbay2  (32G)
   67109026  518828441                                 3  databay2  (247G)

[root@ ~]# gpart status
                              Name  Status  Components
                             da0p1      OK  da0
                             da0p2      OK  da0
                             da0p3      OK  da0
                             da1p1      OK  da1
                             da1p2      OK  da1
                             da1p3      OK  da1
diskid/DISK-6SJ4HSQR0000N23132VXp1      OK  diskid/DISK-6SJ4HSQR0000N23132VX
diskid/DISK-6SJ4HSQR0000N23132VXp2      OK  diskid/DISK-6SJ4HSQR0000N23132VX
diskid/DISK-6SJ4HSQR0000N23132VXp3      OK  diskid/DISK-6SJ4HSQR0000N23132VX

Remove the drive and reseat it in the original drive bay, wait a few seconds at it shows up in gpart just fine:

[root@ ~]# gpart show -l
=>       34  585937433  da0  GPT  (279G)
         34        128    1  (null)  (64K)
        162   67108864    2  swapbay0  (32G)
   67109026  518828441    3  databay0  (247G)

=>       34  585937433  da1  GPT  (279G)
         34        128    1  (null)  (64K)
        162   67108864    2  swapbay2  (32G)
   67109026  518828441    3  databay2  (247G)

=>       34  585937433  diskid/DISK-6SJ4HSQR0000N23132VX  GPT  (279G)
         34        128                                 1  (null)  (64K)
        162   67108864                                 2  swapbay2  (32G)
   67109026  518828441                                 3  databay2  (247G)

=>       34  585937433  da2  GPT  (279G)
         34        128    1  (null)  (64K)
        162   67108864    2  swapbay1  (32G)
   67109026  518828441    3  databay1  (247G)
Comment 1 Ryder Dain 2014-03-10 15:12:50 UTC 
Experienced this exact issue today, same setup, but using environment
FreeBSD srv18 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 =
22:34:59 UTC 2014     root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC =
 amd64

=20=
Comment 2 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:00:20 UTC 
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped