Burn-In Hard drive via GUI for those non CLI users!

[somethingweird]

I don't remember if there was any option to burn in hard drive via gui - Any thoughts?

 

[Redcoat]

There is no GUI option.

See this resource and its use of solnet array test https://www.truenas.com/community/resources/building-burn-in-and-testing-your-freenas-system.38/ or the HDD section in Uncle Fester's Guide maintained by @danb35 at https://www.truenas.com/community/resources/uncle-festers-freenas-beginners-guide.120/ for suggestions.

 

[somethingweird]

There is no GUI option.

Then shouldn't there be one (eventually??)

 

[Arwen]

Perhaps.

However, for those who buy packaged servers with hardware support from iXsystems, the original and replacement drives likely come pre-burned in. So it would not likely be a feature the Enterprise customers would need.

 

[somethingweird]

However, for those who buy packaged servers with hardware support iXsystems, the original and replacement drives likely come pre-burned in. So it would not likely be a feature the Enterprise customers would need.

:(

 

[Davvo]

It's quite easy to burn-in with jgreco's script. You just have to learn a bit of terminal basics... that you would be learning anyway if you were to stick with TN.

 

[probain]

There should be a GUI option.

Please vote for it here, Jira Ticket NAS-124961

 

[MrGuvernment]

Sure, but in the mean time it is literally:
1. Enable SSH
2. log into truenas with WinSCP
3. Upload script noted above
4. SSH into trueNAS and to direct of script
5. run script.

To be honest, if you want to use TrueNAS and do things like load test your config to make sure it is performing, learning a couple very very basic 101 CLI commands, will be useful.

 

[Etorix]

Then shouldn't there be one (eventually??)

No, because there is no generally agreed standard for burning-in drives. It is the user's responsibility to chose a procedure which suits him.

 

[diskdiddler]

I can chime in here, but it's Windows stuff.


I get all new hard drives and format them in a Windows PC - even if it's over USB in the caddy / case still.
I quick format the disk, then use the old USB testing tool, h2testw on the disk. It writes all bytes and reads all bytes.
IT TAKES A LONG TIME

I then run, a SMART full test on the disk.
IT TAKES A LONG TIME.

If my disks, pass both those tests without issue, then I put them in the NAS.
Yes it takes literally an extra 4 to 10 days to put my new hard drives in my NAS, however I know then, that while they might still break, they at least worked when I put them in and they may not have "a bad bit on them" near the 2/3 mark or something, which has stung me, twice before.

 

[joeschmuck]

I do have to agree that it is a personal preference and speaking for myself, the end user should learn these little tasks as maintaining the NAS will be much more difficult once problems creep up. If you are not comfortable with the CLI, this might not be the solution for you. I'm not trying to be mean at all, it's very serious. Your datas safety relies on your knowledge of running the NAS and when issues come up, knowing how to fix them. The links @Redcoat provided are great resources, I know I have read them a few times myself.

 

[Etorix]

As @diskdiddler illustrated, it is recommended to somehow burn-in drives before putting them "in production" in the NAS, but it is NOT specifically recommended to burn-in the drives in place, in the NAS; burn-in can be done in any other system, using any OS, any tool(s), and any procedure which suits the user.
If one uses a destructive procedure, such as badblocks -w, doing that outside of the NAS at least prevents erasing an active pool member by mistake.

 

[Constantin]

Yes it takes literally an extra 4 to 10 days to put my new hard drives in my NAS, however I know then, that while they might still break, they at least worked when I put them in and they may not have "a bad bit on them" near the 2/3 mark or something, which has stung me, twice before.

I'd argue that the time it takes for the test to complete is a feature, not a bug. Put the drive in a non-ventilated external SATA dock and after 4-10 days of h2testw, the HDD will have run hotter & harder than it likely will inside the NAS. Less expensive docks only offer USB, the more expensive ones offer eSATA as well. Such docks are also useful for drive wipes. There is also a mac-native version of h2testw called F3XSwift. I have yet to use that as I preferred running h2testw via Parallels. Linux folk likely would prefer badblocks.

 

[Davvo]

Yes it takes literally an extra 4 to 10 days to put my new hard drives in my NAS, however I know then, that while they might still break, they at least worked when I put them in and they may not have "a bad bit on them" near the 2/3 mark or something, which has stung me, twice before.

Quoting Valerie Henson in this article:

In another surprise, they debunked the "bathtub model" of disk failure rates. In this theory, disks experience a higher "infant mortality" initial rate of failure, then settle down for a few years of low failure rate, and then begin to wear out and fail. The graph of the probability vs. time looks like a bathtub, flat in the middle and sloping up at the ends. Instead, the real-world failure rate began low and steadily increased over the years. Disks don't have a sweet spot of low failure rate. ​

The paper is a bit old though.

 

[Constantin]

I now have three qualified He10’s awaiting getting swapped in. I wonder if I should buy more given that they’re being sold for $79 a pop ATM….

 

[joeschmuck]

I now have three qualified He10’s awaiting getting swapped in. I wonder if I should buy more given that they’re being sold for $79 a pop ATM….

Sometimes a sale is a good opportunity to take advantage of.

 

[diskdiddler]

As @diskdiddler illustrated, it is recommended to somehow burn-in drives before putting them "in production" in the NAS, but it is NOT specifically recommended to burn-in the drives in place, in the NAS; burn-in can be done in any other system, using any OS, any tool(s), and any procedure which suits the user.
If one uses a destructive procedure, such as badblocks -w, doing that outside of the NAS at least prevents erasing an active pool member by mistake.

My method also ensures you identify a faulty USB based disk while it's still inside the caddy, so warranty is probably going to be perfect.
It's worked for me on 14 disks (2 batches) now.

Just best to know for sure, they 100% worked before going in the system - it's a few extra days, maybe a week, it sucks but my NAS is safe.

 

[diskdiddler]

Quoting Valerie Henson in this article:

The paper is a bit old though.

I am using disks in a USB enclosure which are still in warranty at that point.
I've been stung at least 3 times in the last 30 years now, with hard drives that have "a bad bit, on them, near the end" so they were fine until they basically filled to a certain point.

My method may not guarantee 0 failures, I never claimed that, but it does guarantee the disks were 100% reliable at least the moment before you shucked and installed them.