SOLVED Recommended Burn-in for an SSD

[NASbox]

I'm planning to upgrade my FreeNAS box, and one of the things that I plan on doing is using an SSD for the boot drive. Given that SSDs have a finite number of writes, it seems unwise to write tons and tons of data just for testing. Am I correct? What is considered best-practice for burning in a new SSD?

 

[Evertb1]

Personally I would not bother. A lot of people are using USB stick as boot device. I don't imaging they have them burned in so why would you do so with an SSD. If you make an habit of saving your FreeNAS configuration you should be good when your boot device fails. A failing boot device is not half as bad as a failing storage device. The couple of times I had a failed USB stick (now replaced with an SSD) I was up and running again within 20 - 30 minutes. I guess you can always use a tool like CrystalDiskInfo to see if the SSD is healthy to begin with.

 

[Stux]

What is considered best-practice for burining in a new SDD?

Don't.

 

[Evertb1]

Don't.

That says it all

 

[Chris Moore]

If you make an habit of saving your FreeNAS configuration you should be good when your boot device fails. A failing boot device is not half as bad as a failing storage device. The couple of times I had a failed USB stick (now replaced with an SSD) I was up and running again within 20 - 30 minutes.

Sage advice. Even with switching to SSD for your boot device, still make the backups. I have been burned a couple times by those failed USB sticks. I don't ever recommend USB boot devices.

 

[Huib]

I'm using mirrored USB sticks on different systems AND have backups of my configs.

It's slower when upgrading but it hasn't failed me yet with GOOD USB drives.

Stay away from the brandless crap. It will burn you. Also don't make your USB sticks the volume for your logs. Put it on another pool. That way there are actually almost no writes on them since Freenas loads to ram on boot.

If it's not a high grade production system I don't see a problem with USB drives (and it saves precious data connectors)

 

[joeschmuck]

Believe it or not I do test out my SSDs. It's not a Burn-In, it's a SMART Long Test. Then I read the results from the status output and ensure I think it's all good. This is a read-only test and gives you a general idea of the health of the SSD.

 

[Evertb1]

I'm using mirrored USB sticks on different systems AND have backups of my configs.

It's slower when upgrading but it hasn't failed me yet with GOOD USB drives.

Stay away from the brandless crap. It will burn you. Also don't make your USB sticks the volume for your logs. Put it on another pool. That way there are actually almost no writes on them since Freenas loads to ram on boot.

If it's not a high grade production system I don't see a problem with USB drives (and it saves precious data connectors)

I don't see a (big) problem with using USB sticks as boot device. If they fail they can be replaced. It's just that I don't want the hassle. I like to have a system without recurrent problems. Getting 3 sticks corrupted in less then 4 months (always during FreeNAS updates by the way) was to much for me. And it is not only "brandless crap" that fails. I actually used usb sticks of a good brand and type (SanDisk Cruser Fit first and later on SanDisk Ultra Fit) in mirror.

And saving a precious data connection? Not always a problem I think. My motherboard for example offers 2 Sata3 connectors, 4 Sata2 connectors and 8 connectors on a onboard LSI SAS2 controller. So I could easily "sacrifice" a Sata3 connector for my boot device.

 

[MrToddsFriends]

Believe it or not I do test out my SSDs. It's not a Burn-In, it's a SMART Long Test. Then I read the results from the status output and ensure I think it's all good. This is a read-only test and gives you a general idea of the health of the SSD.

I do a SMART Long Test on my SSDs as well. But no badblocks/write test as long I see a good reason why this should be done. One such reason would be the emerging of product counterfeiting as seen with USB sticks. Until now I do a write test on USB sticks but not on SSDs.

 

[Chris Moore]

I don't see a (big) problem with using USB sticks as boot device. If they fail they can be replaced. It's just that I don't want the hassle. I like to have a system without recurrent problems. Getting 3 sticks corrupted in less then 4 months (always during Freenas updates by the way) was to much for me. And it is not only "brandless crap" that fails. I actualy used usb sticks of a good brand and type (SanDisk Cruser Fit first and later on SanDisk Ultra Fit) in mirror.

And saving a precious data connection? Not always a problem I think. My motherboard for example offers 2 Sata3 connectors, 4 Sata2 connectors and 8 connectors on a onboard LSI SAS2 controller. So I could easy "sacrifice" a Sata3 connector for my boot device.

This is exactly the thing that caused me to switch to using laptop hard drives for my boot device. I use a pair of 40GB laptop drives in each of my two FreeNAS systems and they have been totally problem free for almost two years. Since they are hard drives, you can do all the testing and check all the diagnostic data that you do with any other drive. You have to manually (with cron) schedule SMART tests but it works fantastically.

 

[joeschmuck]

This is exactly the thing that caused me to switch to using laptop hard drives for my boot device.

And I personnaly see no issues using a laptop hard drive as a boot device, especially if you have them laying around. I have a few laptop hard drives I'm made use of in my ESXi box (the second one). They work so why not put them to good use.

 

[NASbox]

Thanks @Evertb1, @Stux, @Chris Moore, @Huib, @MrToddsFriends & @joeschmuck for the input.

I picked up a cheap Kingston SSD and ran short/long self tests just to make sure the drive isn't a total DOA. I'm waiting for a couple of new cooling fans and then I'll crack open the box and do everything at once.

In my case I put the system database/logs on the boot drive, so a redundant drive should keep the system running unless I am very unlucky. Based on historical usage and rated endurance my current drive will outlive me unless it fails for a reason other than wear.

I didn't change the default, but IIRC it gets scrubbed about 1/week. If there is a problem wouldn't the scrub catch it? Given all the scrubbing, I though smart tests was a bit redundant. I'll bet my boot drive sees more action from scrubs than "real" use-Even with the logs/database on the boot drive..

Thanks again.

 

[joeschmuck]

Scrubbing by default I thought was about once a month, not once a week. Also a scrub is different from a SMART test. A SMART test will tell you if you have had minor or major read/write errors, temperature issues, etc... Keep in mind that a SMART test is just a read operation, it will not wear out the SSD. I would setup the SMART tests the same as your would for spinning rust hard drives. But I agree, a SSD it generally more resilient than a spinning rust drive.

So a quick story... On Dec 22 this year my work Dell laptop had an M.2 SSD fail and a SMART test Failed at a certain LBA. It was still under it's 3 year warranty (that Dell gives) and I had a replacement on my doorstep on 24 Dec. This SSD was only used for normal work use, nothing like a file server, no scrubbing, and it failed. So even SSDs do fail but the reliability it very high. Thankfully none of my data was located in the failed area so it was a fairly easy recovery. Mt point is run the SMART tests, both short daily and long weekly (just my advice) on all drives. If you have a lot of large capacity drives and you use the server all the time, I'd stagger the drive tests to mitigate slow performance issues, but if you are like many home users and the system is not used while you are sleeping, try to do it during those hours.

Good luck and Happy New Year!

 

[Evertb1]

I'd stagger the drive tests to mitigate slow performance issues, but if you are like many home users and the system is not used while you are sleeping, try to do it during those hours.

Good advice. One of the first things I do when adding a drive to the system is to schedule the SMART tests. I use a schedule copied of one of the Forum members that I liked (together with a schedule for snapshots etc. I seem to recall that I "stole" it from @Stux Not sure though.

 

[joeschmuck]

I seem to recall that I "stole" it from @Stux Not sure though.

Naw, I'm sure @Stux gave it away for free :)

 

[NASbox]

Scrubbing by default I thought was about once a month, not once a week. Also a scrub is different from a SMART test. A SMART test will tell you if you have had minor or major read/write errors, temperature issues, etc... Keep in mind that a SMART test is just a read operation, it will not wear out the SSD. I would setup the SMART tests the same as your would for spinning rust hard drives. But I agree, a SSD it generally more resilient than a spinning rust drive.

So a quick story... On Dec 22 this year my work Dell laptop had an M.2 SSD fail and a SMART test Failed at a certain LBA. It was still under it's 3 year warranty (that Dell gives) and I had a replacement on my doorstep on 24 Dec. This SSD was only used for normal work use, nothing like a file server, no scrubbing, and it failed. So even SSDs do fail but the reliability it very high. Thankfully none of my data was located in the failed area so it was a fairly easy recovery. Mt point is run the SMART tests, both short daily and long weekly (just my advice) on all drives. If you have a lot of large capacity drives and you use the server all the time, I'd stagger the drive tests to mitigate slow performance issues, but if you are like many home users and the system is not used while you are sleeping, try to do it during those hours.

Good luck and Happy New Year!

The data pool defaults to 35 days (I know that one), but for some reason the boot drive is much shorter. It's a small SSD, so it doesn't take any time or cause any disturbance, or likely to create significant wear, so I've left it. Given the light usage on the server, I'm comfortable with the schedule. As for frequent long tests, isn't that going to contribute to wear/tear on the actuator mechanism? Given how light the traffic is on my box (used for library, archive and backup.

As for smart (I do know the difference-and I appreciate your story). I was under the impression (maybe wrong) that overtemp and the significant smart error conditions create an alert. On 6TB WD Reds long smart takes about 11.75 hrs - that's a lot of extra wear and tear given the base work load. I can resilver the whole pool almost as fast. I run periodic tests from the shell on an adhoc basis, butf I was running a real time transactional database, I'd be running regular tests..

 

[joeschmuck]

Spinning rust drives benefit from the heads moving across the platter surface ensuring an even wear level on the surface. Also the arm/actuator are a few bearings and magnetic fields, these parts are not what typically wear out first. The parts that wear out are typically the motor (from drives spinning up frequently) or Head Crash (head hits the platter) occur (physical drops or other physical trauma), or sometimes the platter coating will flake off. None of these will occur faster just from using the drives as designed. A read operation should be a minor function for the drive. As for the 11.75 hours for each drive, that is quite a long time but if you can schedule running 1 drive during a single day and then spread those tests out over a week or two, that would minimize performance impacts.

Anyway you can of course do whatever you desire and feels right for you, many people setup FreeNAS in different ways and yours is not wrong.

 

[NASbox]

Spinning rust drives benefit from the heads moving across the platter surface ensuring an even wear level on the surface. Also the arm/actuator are a few bearings and magnetic fields, these parts are not what typically wear out first. The parts that wear out are typically the motor (from drives spinning up frequently) or Head Crash (head hits the platter) occur (physical drops or other physical trauma), or sometimes the platter coating will flake off. None of these will occur faster just from using the drives as designed. A read operation should be a minor function for the drive. As for the 11.75 hours for each drive, that is quite a long time but if you can schedule running 1 drive during a single day and then spread those tests out over a week or two, that would minimize performance impacts.

Anyway you can of course do whatever you desire and feels right for you, many people setup FreeNAS in different ways and yours is not wrong.

You've given me something to think about... I might reconsider what I'm doing.