Allow assigning spares to the boot pool

Feature Requests
1

Problem/Justification
I understand that it may not be possible to do N-mirrored boot pools, but assigning spares would get most of the way there.

Impact
It provides an extra option to minimize the risk of losing the boot pool. I don’t know of any disadvantages, other than that it requires one or more “wasted” drives (but welcome to replication).

User Story
The bad situation:

  1. User is away on holiday/asleep/at work on the ISS/drunk, or otherwise not immediately available.
  2. First drive fails. There are extra drives which could be assigned to the boot pool, but the user is not available to log in and manually assign the new drive.
  3. Second drive fails. Now there is no boot pool. Oops.
  4. Temporary power loss. Now the user can no longer stream Columbo from home until they get back to Earth to fix everything.

The good situation:

  1. User is away on holiday/asleep/at work on the ISS/drunk, or otherwise not immediately available.
  2. First drive fails.
  3. A spare drive is immediately swapped in, likely finishing the mirror in a few seconds.
  4. Twelve nines of Columbo uptime maintained.
2

One downfall (one that is shared with simply having a single mirror of the boot pool) is that if the boot pool doesn’t suffer a failure that causes it to be fully invisible to the motherboard, it is quite common to have to go into the BIOS & actually select the 2nd assumed working boot drive.

Spare boot is less of bulletproofing & more of a time reduction vs re-installing & uploading config for systems that either need high uptime or for users (like myself) that aren’t always as religious about backing up config as they should be.

3

That’s a good point. So really the utility of this is going to be quite variable across motherboards and scenarios.

Maybe we can also install a little bit of thermite in each drive and automatically blow up its controller whenever it looks at us funny :smiley:

1 Like
4
3 Likes
5

What? Of course it is, always has been. Well, since 9.3 anyway.

Not that this is a very realistic scenario, to be honest.

6

“Possible” and “exposed through the installer/GUI” are two different things. It can, of course, be done at the CLI, though I expect getting the bootloader installed properly would be a little fiddly. It used to be exposed through the installer, but I understand that’s no longer the case. And it’s never been available through the GUI AFAIK.

But the situation where you’re going to fail two boot devices before you can get skilled hands on the system seems a little fanciful.

7

I think your situation could be also solved with KVM such is PiKVM or TinyPilot.
This way you can get into BIOS remotely and reassign boot drive to spare one manually and even solve other problems.

8

…or better yet, IPMI, which your server motherboard should have anyway. But that doesn’t really solve the stated problem[1]–it can adjust the boot order, but it can’t resurrect the failed second drive.

  1. though it highlights another one, in that a boot device failure doesn’t mean the system will automatically roll over to booting from its mirror ↩︎

1 Like
9

It isn’t? Is that a Scale thing? Last Core install I did offered the usual options and everything was straightforward.

At least in Core it’s been available for a while, though the “a while” part goes without saying for features in Core, sadly.

1 Like
10

Making an n-way mirror where n > 2 has been in the CORE GUI for a while?

11

@nintendoeats I think you have your answer, you need hardware for a true mirror setup to have it be fault tolerant.

12

I confirm.

13

The GUI is there, is it limited to two disks? Because that would be silly and easy to patch out.

14

The CLI Is also limited to two disks for some reason too.