Project

General

Profile

Feature #744

Replacing drive results in 'wrong' id used in ZFS pool

Added by Antoni Baranski almost 10 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Nice to have
Assignee:
William Grzybowski
Category:
Middleware
Target version:
Estimated time:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

Description

After doing an in place replacement of a dieing drive I have the following:

NAME                                            STATE     READ WRITE CKSUM
storage1 ONLINE 0 0 0
raidz2 ONLINE 0 0 0
ada0p2 ONLINE 0 0 0
gptid/f3d00bc0-a562-11e0-93da-001b21ad7873 ONLINE 0 0 0
gptid/f49ae910-a562-11e0-93da-001b21ad7873 ONLINE 0 0 0
gptid/f5672129-a562-11e0-93da-001b21ad7873 ONLINE 0 0 0
gptid/f64efe95-a562-11e0-93da-001b21ad7873 ONLINE 0 0 0
gptid/f76d9183-a562-11e0-93da-001b21ad7873 ONLINE 0 0 0
Note the BOLD id.

In the UI I see this for the drive: {uuid}521a85f7-d6f4-11e0-8832-001b21ad7873

NOTE: Replacement worked as a charm.

History

#1 Updated by Josh Paetzel almost 10 years ago

This is a cosmetic issue that we'll look at addressing in the future. The database and system contain the correct info for the drive.

#2 Updated by Antoni Baranski almost 10 years ago

Am I correct in understanding that its the GEOM label which is not set properly on the drive?

#3 Updated by William Grzybowski almost 10 years ago

Not quite, that is because in the zpool replace command the disk name is used instead of gpt/xxxxx-xxxx-xxx, but they both "point" to the same location...

#4 Updated by William Grzybowski almost 9 years ago

Since 8.2.0 using gptid is the default devname being used to create pools and will remain as such to avoid issues with spares disks and device renaming...

Also available in: Atom PDF