Moving Boot from USB to SSD

[NumberSix]

Hi
My setup currently relies on a 32Gb USB stick to boot from and I would like to know how feasible it is to switch the boot to the SSD that's already part of the setup. The setup is: 2 mirrored HDD which hold the 'data' pools. plus one SSD which houses the System dataset pool. Is there a step-by-step guide anywhere on how to do this, written with full details (for nervous noobies)? My initial concern is how to put the boot files on there at all, and also how to do that without blowing away the system pool. Also, I'm really not that clear on how to backup (or reinstate) the system pool; surely a related requirement I am guessing. Can anyone point me in the right direction for this?

Incidentally, thinking also about whether this is a good idea: the writes to the System pool are already non-stop 24 hours a day, running between 8 & 32 kbs. Is that normal? What on earth is it finding to do that requires round the clock writes when I use the system for only about an hour a day? I would imagine this will slash the life of the SSD, and if so, perhaps i'm better leaving the boot system on the USB? Thought there too please! Thank you.

 

[danb35]

Really, the simplest thing to do is to do a fresh install to your SSD of choice, then upload your config file to that installation.

What on earth is it finding to do that requires round the clock writes when I use the system for only about an hour a day?

Probably writing log files, but there's quite a bit that's stored there.

 

[NumberSix]

Thank you for that. Are there any beginners guides on how to do that, specifically :
* how to save a config from the SSD
* how to transfer boot code from the USB to the SSD
* crucially, how to copy the config back to the SSD

I presume between step 2 and step 3 I'd need to change the Bios to try to boot from SSD by first preference, too.

And I should assume the constant & perpetual 8k-32k writes to the SSD 24 hours a day won't wear out the SSD sooner (& so kill it's ability to boot up) than just relying on a USB stick would do?

Thanks again!

 

[danb35]

* how to save a config from the SSD

In the GUI, System -> General -> Save Config

* how to transfer boot code from the USB to the SSD

You don't transfer anything, you just install to the SSD

* crucially, how to copy the config back to the SSD

System -> General -> Upload Config

And I should assume the constant & perpetual 8k-32k writes to the SSD 24 hours a day won't wear out the SSD sooner

I wouldn't think so, but if you're concerned, you could always put the .system dataset on the spinners.

 

[Stux]

You can do this by adding your SSD as a mirror to your existing boot device. Then removing the existing boot device from the mirror.
I'm incorrect here. You can't (or shouldn't) because your USB bootpool will be ashift=9, and you probably want atleast ashift=12 for your SSD.

https://jira.ixsystems.com/browse/NAS-108568

 

[NumberSix]

Hi
Thank you for that update, but I have to ask now, what is 'ashift' and why does it matter in this context?

Thanks!

P. S. That link won't load for me. It may be temporary, but I thought I'd mention this in case the answer to my questions are on the other end :)

 

[Vertigo 7]

Looking for some similar information, myself. I currently have 2 USB thumbdrives on an internal header in a mirrored boot pool but I'm going to replace them both with USB SSD drives with the goal of using the same header. What's the best practice for doing something like that? Assuming just as above, save config, install fresh, load config

 

[Etorix]

Assuming just as above, save config, install fresh, load config

Yes.

Thank you for that update, but I have to ask now, what is 'ashift' and why does it matter in this context?

"Ashift" is the size of file system sectors according to the formula: Size (bits) = 2^ashift. Ashift=9, 512 bit sector; ashift=12, 4096 bit sector.
Sectors smaller than the actual sector size of the device cause write amplification. For instance, writing a single 512 bit logical sector on a device with 4096 bit physical sectors involves reading, modifying and rewriting the 8 logical sectors in a 4k physical sector.

 

[Stux]

Yes.


"Ashift" is the size of file system sectors according to the formula: Size (bits) = 2^ashift. Ashift=9, 512 bit sector; ashift=12, 4096 bit sector.
Sectors smaller than the actual sector size of the device cause write amplification. For instance, writing a single 512 bit logical sector on a device with 4096 bit physical sectors involves reading, modifying and rewriting the 8 logical sectors in a 4k physical sector.

And you can't change the ashift after pool/vdev creation. And that's the problem when your boot vdev is ashift=9