SOLVED About multiple copies for single device boot pool

[Davvo]

I happen to have a single SSD as my boot-pool and it is massively oversized for its role; it made me think if it would be possible (certanly not from the GUI) to artificially create redundancy using the copies value. I did not manage to find much on the forum, and google was't helpful either.
I hardly think that it would provide useful since we are not talking about spinning rust with sectors that can become unreadable, and my impression of flash memory is that it either dies completely or continues living, but please correct me if I am wrong.
Maybe such redundancy is already present in the boot pool given its nature, but again I wasn't really able to find anything about the boot pool specifically.
Can anyone point me at the right direction?

 

[NugentS]

I thought copies was only metadata - I've been known to be wrong though

 

[Davvo]

I thought copies was only metadata - I've been known to be wrong though

As far as I know ZFS stores 2 copies of metadata and 3 of important metadata as default when a copy value is 1, but I'm not clear if this only applies to normal pools (since that was always the context of the discussions). Regardless, if my understanding is not wrong it's possible to have multiple data copies on the same drive (look at dataset option "copies").

 

[Jailer]

As long as you have a backup of your configuration I don't see why you would bother with any of this for a boot drive. If you boot device fails just replace it re install TrueNAS and upload your saved config.

 

[Davvo]

As long as you have a backup of your configuration I don't see why you would bother with any of this for a boot drive. If you boot device fails just replace it re install TrueNAS and upload your saved config.

Mainly because I want to know all the options and get as much as I can from what I have.
Also, I see this as an opportunity to increase my knowledge about flash since it's a bit lacking compared to plates.

 

[Arwen]

Yes, you can set "copies=2" and get all standard metadata bumped up to 3 copies, and data bumped up to 2 copies. (Critical metadata can't go beyond 3 copies as far as I know.)

Of course, unless you did some tricks, the "copies=2" would only apply to newly written blocks. (The trick is to re-write all existing data, to force the blocks to have 2 copies.)

@NugentS, yes "copies" applies to file data blocks. A poor man's mirroring. (Or extreme protection when using other redundancy..)


All that said, @Jailer is right in that it would likely be simpler to replace your boot drive. (You should already have a config file backup scheme...)

 

[Davvo]

Yes, you can set "copies=2" and get all standard metadata bumped up to 3 copies, and data bumped up to 2 copies. (Critical metadata can't go beyond 3 copies as far as I know.)

Of course, unless you did some tricks, the "copies=2" would only apply to newly written blocks. (The trick is to re-write all existing data, to force the blocks to have 2 copies.)

I didn't know both the metadata limit and the new writes issue. How do you force the boot pool ti re-write existing data? Before that, how do you set the copies=2? I guess from the cli since the boot pool doesn't show in the GUI.

All that said, @Jailer is right in that it would likely be simpler to replace your boot drive. (You should already have a config file backup scheme...)

I mean I agree. I'm actually dubious if it would event matter having multiple copies on SSD.
This thread doesn't stem from necessity but from curiosity.

 

[Arwen]

To get the boot-pool using all "copies=2", you have to:

• Shutdown the TrueNAS server
• Boot to alternate media that supports ZFS, like Ubuntu
• ZFS send the boot-pool and receive in an alternate location
• Remove all the files from the boot-pool, (but DON'T destroy it!!!)
• Set "copies=2" on the boot-pool
• Use ZFS send from the alternate location, to the boot-pool
• Make sure the datasets are at the correct level, (I've accidentally sent them to a child dataset)
• Make sure all child datasets inherited "copies=2"
• Hope and pray to the ZFS gods that you got it right
• Shutdown and boot to the updated boot-pool

If it worked, don't forget to clean up the temporary snapshot you used for the original ZFS send.


As for the metadata limit, ZFS metadata has 3 slots for copies. Normal metadata, like directory entries use 2 for sub-directories. Thus, any file should be covered for complete loss of 1 directory entry, causing zero data loss.

If using ZFS native encryption, one slot is taken up, leaving standard metadata at 2 copies, even when "copies=2", (or "copies=3"). Plus, regular data is also limited to 2 copies as well.


EDIT: I forget the step of removing the child datasets after removing all the files on the boot-pool. I guess you can use ZFS destroy on those child datasets to simplify removing the files... But don't destroy the boot-pool!!!

 

[Davvo]

To get the boot-pool using all "copies=2", you have to:

• Shutdown the TrueNAS server
• Boot to alternate media that supports ZFS, like Ubuntu
• ZFS send the boot-pool and receive in an alternate location
• Remove all the files from the boot-pool, (but DON'T destroy it!!!)
• Set "copies=2" on the boot-pool
• Use ZFS send from the alternate location, to the boot-pool
• Make sure the datasets are at the correct level, (I've accidentally sent them to a child dataset)
• Make sure all child datasets inherited "copies=2"
• Hope and pray to the ZFS gods that you got it right
• Shutdown and boot to the updated boot-pool

If it worked, don't forget to clean up the temporary snapshot you used for the original ZFS send.

I never thought of using another OS for it, that looks fun.

If using ZFS native encryption, one slot is taken up, leaving standard metadata at 2 copies, even when "copies=2", (or "copies=3"). Plus, regular data is also limited to 2 copies as well.

Another thing learned!

Thank you all for talking time to share your wisdom.