Was thinking that if you had a boot disk with many many boot environments… say nightlies… dedupe would really allow you to get some space savings 
Most nightlies are very similar on a file by file basis I think, but they aren’t clones.
And then the copies would allow bitrot protection
…all of that in a zvol for virtualised TrueNAS on TrueNAS, I suppose?
Principle: Why make it simple when you can make it complicated?
Corollary: Why make it complicated when you can make it inextricable?
Of course, if it was on TrueNAS, I wouldn’t use copies=2.
It would need testing to validate - but I would expect there is read speed advantages having multiple copies. This assumes that ZFS can understand that there are multiple copies that it can read from.
Coming from a MS landscape, this is the reason there are multiple copies along with redundancy, something mildly more advanced than a RAID esque approach.
While I can come up with some hypothetical scenarios of how to squeeze more speed (read IOPS to be precise) from it, it’s hard to believe that developers have spent time on this feature. OTOH, sometimes developers even spend time on animated poo.
Sounds interesting. Can you provide some links?
Granted its not the primary reason, its a pretty useful benefit. The storage efficiencies are horrid if you are looking for “maximum storage and minimal performance” - this is the other end of the scale.
IIUIC, the article is about multi node copies. And this topic is about single node disk copies.
I signed up for this forum to praise @winnielinnie
I read the whole thread and decide to stop using copies=2.
Thank you for saving my time and money!
I’ve not re-read this entire thread, so this may have been covered. The best use case for “copies=2” in the TrueNAS context is for a single boot-pool device. Really for SSD or NVMe, (even if over USB), boot-pool devices. Stock cheap USB flash drives would likely not work well with the additional writes…
Those users that need higher availability of their NAS, but don’t have the ports or device for a 2nd boot device, can use “copies=2”. It’s not perfect, but does increase reliability and uptime. Further, with smaller SSDs & NVMes being in the >100GBs range, there is little reason not to use the space. Hey, even “copies=3”!
That is an interesting idea, but I wonder why you think this would boost uptime.
Would it even be able to decide form wich copy to boot from?
Would you select that with a bootloader?
And why should my SSD fail on let’s say 0-100GB but not on my second copy 100-200GB? IMHO if something goes wrong SSDs, it really goes wrong aka not showing up anymore.
How would you detect it, just manually by looking at it?
That’s not what “copies=2” means.
Each block is stored twice. With a checksum. In the event that a block can’t be read correctly, the other is used, and the faulty block is corrected.
I used to run Proxmox on a PC with a single NVMe slot, and I used a consumer-grade NVMe SSD. After a couple of years, dmesg started showing critical medium errors on reads from certain LBAs. ZFS detected the errors, but couldn’t recover the data, of course, so I restored it from a backup. A few months later, a couple more errors showed up, so I replaced it and reserved it to investigate later.
Some time later I ran some tests on it. Reading from these addresses still failed with the same errors, but writing must have made the controller relocate them to spare cells, because I could then read from them reliably again. I filled up the entire drive, powered the whole system down, and read it back, repeating this cycle multiple times to ensure it wasn’t just reading from a cache, and that it wasn’t relocating the bad cell to another accessible address.
So far, it looks like the error rate is not increasing, unlike other SSD failures I’ve had in the past. The drive is still usable so long as bit rot is actively detected and repaired on reads.
copies=2 might have saved me my data, and now is saving me money.
I like your story, but:
copies=2 you get X/2 usable storage for Y money (where Y is the price of a drive with X total space).First case would protect from some LBA failures and… that’s about it. The second case would also protect from controller failures (welp, if that’s not a firmware bug, you can use different model drives to mitigate this risk) and other drive failures (I’ve once cut a condenser from my cheap optane with a fingernail during install in a confined space).
So, you are mitigating more risks for the same price (storage/money ratio wise). The downside is the need for an additional slot, but you can usually use a pcie-m2 adapter.
I agree that mirrors are strictly better, of course.
But I disagree with the sentiment that it’s useless. For science, I’ll put this drive in a single-drive pool with copies=2 and update this thread once I have successfully recovered some data.
The need for an additional slot may actually be a big issue for a small build (e.g. mini-ITX X10SDV or A2SDi, which have a single M.2 slot).
Cutting usable storage in half is basically a non-issue for most boot devices (half of a $10 second-hand 128 GB SSD from laptop upgrade is still plenty), and might not be an issue for an app pool as well. I’d say that @gabriel 's user story makes a great case why and how copies=2 may be useful for the boot pool and/or app pool on a home NAS.