Project

General

Profile

Bug #9365

Unfortunate behavior WRT mirrored boot devices

Added by Josh Paetzel over 5 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Important
Assignee:
Sean Fagan
Category:
OS
Target version:
Seen in:
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:
ChangeLog Required:
No

Description

The installer will not let you install to two different size devices in a mirror, however if you install to the smaller device, then attach the larger device through the GUI after the install you can get a mirror. The GUI however does not match the gpt partition size of the existing device when creating the gpt partition on the new device, it uses all the space on the larger device you are attaching.

So say you then detach the smaller device, or it fails. If you reboot your FreeNAS system in that state the boot pool will expand to fill the gpt partition of the single larger device...thus creating a situation where you cannot reattach your original device once it is replaced.

This is unexpected behavior. The system should either refuse to use devices of disparate sizes unilaterally, or it should DTRT and partition the devices to match the smallest device selected.


Related issues

Copied to FreeNAS - Bug #9425: GUI needs to handle boot-device mirroring better nowClosed: Not To Be Fixed2015-04-22

Associated revisions

Revision 9d8e6c70 (diff)
Added by Sean Fagan over 5 years ago

When creating a mirrored pool during install, use the smaller of any sizes. And round down a bit as well, but that's mostly to make the math easier. Ticket: #9365 Merge-FN93: Yes Merge-TN93: Yes

Revision d1d3bccc (diff)
Added by Sean Fagan over 5 years ago

When creating a mirrored pool during install, use the smaller of any sizes. And round down a bit as well, but that's mostly to make the math easier. Ticket: #9365 Merge-FN93: Yes Merge-TN93: Yes (cherry picked from commit 9d8e6c70a0482918c12c73400930f54d6ef7e450)

Revision 2337ccf6 (diff)
Added by Sean Fagan over 5 years ago

When creating a mirrored pool during install, use the smaller of any sizes. And round down a bit as well, but that's mostly to make the math easier. Ticket: #9365 Merge-FN93: Yes Merge-TN93: Yes (cherry picked from commit 9d8e6c70a0482918c12c73400930f54d6ef7e450)

History

#1 Updated by Jordan Hubbard over 5 years ago

  • Assignee set to Sean Fagan
  • Priority changed from No priority to Important
  • Target version set to Unspecified

#2 Updated by Sean Fagan over 5 years ago

  • Status changed from Unscreened to Closed: Behaves correctly

This is actually desired behaviour, because this is how you can grow your boot device size.

We've had quite a few discussions about this, remember Jordan?

#3 Updated by Sean Fagan over 5 years ago

Also, the installer most certainly does let you mirror different-sized devices. I just tried it.

#4 Updated by Jordan Hubbard over 5 years ago

I didn't file the bug - Josh did. You should have this conversation with him. :)

Also, FWIW, it's pretty clear that regardless of however many conversations we've had, people are running into a lot of trouble with the current installer behavior that just gloms onto the whole stick, right down to the last block. I think what Josh is asking for is an optional partitioning step, since that would solve the problem without losing the ability to grow your boot device.

#5 Updated by Josh Paetzel over 5 years ago

I don't believe behaves correctly is the right status for this bug.

The behavior of the current system has resulted in two reinstalls this week by FreeNAS certified customers (one of whom is watching this bug)

If the installer will let you use two differently sized devices then the easy button solution is two partition both devices to the same (smaller) size.

You can easily grow partitions with gpart resize, it just requires an explicit action, which seems safer than implicitly growing at any opportunity.

#6 Updated by Sean Fagan over 5 years ago

See my other comments in the other bug for why adding a partitioning step is problematical.

Even doing the minimum size is not all that easy.

#7 Updated by Sean Fagan over 5 years ago

If we add UI to the system to partition new boot devices, and to change the partition sizes, and I'll add code to the installer to use the minimum size of all the disks.

Doing the former by itself is useful; doing the latter without the former isn't so much.

#8 Updated by Josh Paetzel over 5 years ago

Changing the GUI in the running system won't solve the problem because the installer alone is setting up the partitions in such a way that the problem will occur.

1) Install two two different sized devices in a mirror.

2) Remove the smaller device.

3) Reboot the system.

Pool grows to fit the larger device. This is unavoidable automagical ZFS behavior.

At this point you can no longer use the smaller device.

I agree that detecting the device size and using the smallest device to partition all of the devices is more complicated than the current code, but it's not "makes the system hideously complicated or fragile" territory.

#9 Updated by Sean Fagan over 5 years ago

  • Status changed from Closed: Behaves correctly to Investigation

I give up. Doing this is dumb, short-sighted, and will cause at least as many problems as it is trying to fix, but that doesn't seem to matter.

  1. The actual description is wrong, since it does work.
  2. Picking the minimum won't solve the problem, because when a device dies -- as it will, since we're talking about thumb drives -- the replacement, even if it's the same manufacturer and model and alleged size, could fail due to being smaller.
  3. Speaking of which, the post-install mirroring and replacement needs to be changed as well. Unless we're blowing off that complaint too.
  4. Rounding the size down (as per another bug) means that people will complain that their 8gb drives actually only have about 6.5g for ZFS. I'm sure that'll cause no problems whatsoever.
  5. Saying "they can fix it in the command line" also means that they could fix this in the command line. (I, for example, did that when I created a mirror for my boot device. I admit to being unusual here, but somehow we're saying that using the command line is good, and yet it's also not good.)

#10 Updated by Sean Fagan over 5 years ago

  • Status changed from Investigation to Ready For Release
  • ChangeLog Entry updated (diff)

#11 Updated by Sean Fagan over 5 years ago

  • Copied to Bug #9425: GUI needs to handle boot-device mirroring better now added

#12 Updated by Jordan Hubbard over 5 years ago

  • Status changed from Ready For Release to Resolved

#13 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Target version changed from Unspecified to N/A

Also available in: Atom PDF