Boot Device(s) immediately degraded...and then get worse

[disinterredsoulbox]

Hello All,

I've followed the forum for a while but am compelled to post for the first time, as I can't seem to find an answer or solution.

I cannot seem to achieve a clean install. EVERY attempt results in immediate boot-device degradation (like, upon first boot). Boot is successful, but with an alert ("
Boot Pool Status Is DEGRADED: One or more devices has experienced an error resulting in data corruption. Applications may be affected.")

Initial scrubs usually give a low-number (40-80) checksum value, but nothing is repaired, and subsequent scrubs just indicate worsening checksum values.

This has been installed on (3) SanDisk 128GB SSD on two machines (a "learning" machine, and a "production" machine); both experience the same result.

Learning:
Supermicro X7DBU
2x Intel Xeon X5650
98GB ECC RDIMM
FreeNAS 11.2-U6
Boot Device = SanDisk 128GB SSD SATA (via Supermicro chassis backplane)
raidz-1 pool of 3 - 2TB WD HDDs

Production:
Supermicro X8DTi-F
2x Intel Xeon E5620
12GB ECC RDIMM
FreeNAS 11.2-U6
Boot Device = SanDisk 128GB SSD SATA (via Supermicro chassis backplane)
no HDDs or pools created yet (until I figure out this boot thing...)

I have tried:
installing 11.2-U5 from flash drive (created with rufus) and upgrading
installing 11.2-U6 from flash drive (created with rufus)
installing 11.2-U5 from CD (win32diskimager) and upgrading
installing 9.1.0 from CD and flash drive and upgrading
(all images display the correct checksum)

zero-overwrite of drives between attempts, successful S.M.A.R.T. tests performed.

 

[disinterredsoulbox]

Hmm...seemed to have posted the above by accident. Wasn't quite done.

I will happily provide the results of

Code:

zpool status -v

if someone will give me an idea of how to copy/extract that (ctrl-c doesn't seem to do it....)

Preview version is data set is in excellent health, boot is ill, and seems to involve a lot of files I don't understand (among other things) stemming from //usr/local/lib/python3.6/site-packages/

Would love to hear your thoughts, and am happy to provide other info y'all might need. I'm relatively noob, so be gentle, please! Grateful in advance!

 

[disinterredsoulbox]

Figured out how to copy the output of status -v. Attached.

 

[anmnz]

Simplest answer: get a different SSD to boot from.

This is a problem with the controllers used in those SanDisk SSDs, and some others.

See this bug report. It contains links to other forum threads where this has been discussed.

https://jira.ixsystems.com/plugins/servlet/mobile#issue/NAS-100276

 

[disinterredsoulbox]

Given that the consistent variable was the same SSDs, I was suspicious of the disks, but couldn't figure out why. Thanks for the link! I could not find anything with that sort of specificity. I appreciate the help!

 

[cobrakiller58]

I disabled trim on my boot ssd's so I would not have to replace them. Alexander Motin posted the command in that bug report.

 

[pschatz100]

I disabled trim on my boot ssd's so I would not have to replace them. Alexander Motin posted the command in that bug report.

If disabling trim solved your problem, then great. With a 128Gb SSD, there is a lot of unused space, so trim actually provides little to no benefit in this particular case.

 

[disinterredsoulbox]

Thanks for the replies, all. 128GB is more space than I need, but they were the cheapest I found (per GB, smaller capacity cost as much as the 128s). Perhaps too cheap, it might seem. That being said, I am curious how the trim thing works with respect to this issue. From what I was reading in the link provided above, trim seems to be a tunable that you set in FreeNAS, and doesn't fix the corruption, per se. Please correct my ignorance, but for trim to be enabled, I would have to boot. Said boot is already corrupted. Does the trim setting remain on the disk itself, and make it useful for future reinstall, or is it only applied while the system is running? If it does persist, does it do so even after an overwrite/format? Otherwise, disabling trim from a corrupted boot wouldn't seem to solve anything, unless I am missing something (which seems quite plausible).

I'm all about the saving money where I can, but I have ordered some new SSDs. I'm willing to pay a bit more for confidence in my system, especially if I am planning on using it to store invaluable data. Cause I am. It's not like the SanDisks will go to waste; its always nice to have a couple SSDs laying around!

Thanks again for all the help!

 

[cobrakiller58]

If you set the tunable immediately after a fresh install or the update that started this (which is when I did it) the only checksum errors that will be detected during scrubs will be real errors and if it is mirrored will be repaired unless it is hardware related. It has been perfectly stable for me running with trim disabled on my boot SSD's but if it makes you uncomfortable make sure you identify the controller in the SSD's you plan to order for boot drives before you order them or else you will end up with the same error.

As for a full understanding of the issue, that is far far out of my league.

 

[pschatz100]

TRIM is an ATA command that enables an operating system to tell an SSD which data blocks it can erase because they are no longer in use. The use of TRIM can improve the performance of writing data to SSDs and contribute to longer SSD life. I think of it as "wear leveling" in the sense that TRIM spreads writes across the available sectors of an SSD. Trim function becomes more important as an SSD fills up.

Using a 120Gb or 128Gb SSD as a boot device provides lots of available space for writing. In fact, that is what I use. When you are using only a few percent of an SSD's capacity, then Trim is irrelevant. If turning it off allows the Sandisk SSD to work OK, then don't worry about it.