Drive Badblocks Burn-in Tests - "sysctl kern.geom.debugflags=0x10" not possible on SCALE 24.04.1.1

Hello,

at the moment I am trying to do the burn-in tests for my new drives, but the “sysctl kern.geom.debugflags=0x10” as preparation for the badblocks test does not work.

If I try to run it on the console I get:

sudo sysctl kern.geom.debugflags=0x10
sysctl: cannot stat /proc/sys/kern/geom/debugflags: No such file or directory

If I try to set it on the WebUI under System Settings => Advanced => Sysctl as:
Variable: kern.geom.debugflags
Value: 0x10
It shows the error: “Sysctl ‘kern.geom.debugflags’ does not exist in kernel.”

Any ideas?

Thanks a lot in advance,

Thomas

I’m pretty sure that’s a FreeBSD-specific command. Try running badblocks anyway and see if it completes.

4 Likes

This will require some research and testing. Dragonfish 24.04.1.1 is locked down pretty hard.

Have you just tried to run the badblocks command? If Yes, what message do you get back?

This command (FreeBSD Only) allows you to write data to a drive as you see fit, so badblocks can overwrite data at will.

1 Like

I just kicked off a session of badblocks on SCALE 24.04.1.1 on a single test drive, so far so good but I won’t know anything until the thing has completed, which could be a long time (approx 3.5 hours). I am only running a single pass with a specific test pattern on the entire disk. I thought about running only on about 5% of the drive but I opted to test the entire thing so see if I have any issues on this old drive. Also, this drive is not assigned to any pool, it is just there and TrueNAS sees it as an available drive.

The command I used: badblocks -wfsvt 0xaa /dev/sdd (Don’t Use -f)
badblocks -wsvt 0xaa /dev/ssd

This should run badblocks in (w)Write Mode, and (f)Force it, (s)Showing Progress, (v)Verbose, and (t)Test Pattern of 0xaa.

I did not do anything else other than login as root.

When I am done I will attempt to dump a few sectors from the drive to verify the test pattern was written.

1 Like

Yes sir, badblocks does run just fine from the SCALE 24.04.1.1 command line interface. It came back completed with this screen:

root@truenas[~]# badblocks -wfsvt 0xaa /dev/sdd
Checking for bad blocks in read-write mode
From block 0 to 488386583
Testing with pattern 0xaa: done
Reading and comparing: done
Pass completed, 0 bad blocks found. (0/0/0 errors)

To view the data on the drive I used:
dd if=/dev/sdd bs=512 skip=900 count=500000 | hexdump -C

root@truenas[~]# dd if=/dev/sdd bs=512 skip=900 count=500000 | hexdump -C
00000000  aa aa aa aa aa aa aa aa  aa aa aa aa aa aa aa aa  |................|
*
0f424000
500000+0 records in
500000+0 records out
256000000 bytes (256 MB, 244 MiB) copied, 2.66377 s, 96.1 MB/s

Everything is value “aa” which is what I told it to write.

If you want to run it normally (all default test patterns) then use:
badblocks -wfsv /dev/sd?? “Where sd?? = your drive.”

Hope this helps, I’m sure it will help others using SCALE and wanting to run this on some drives to burn them in.

Well that was fun.

3 Likes

I don’t think I’d recommend using the -f flag. Normally it will refuse to test a drive that’s in use; the -f flag overrides this protection. But to avoid 16-bit counter overflows, specifying a large block size can be helpful: badblocks -wsv -b 65536 /dev/sd??

I did not try using it without the -f flag. Not sure what Dragonfish would allow regardless that the drive was not assigned to a pool.

Just tested without the -f and it works. I only changed a few million sectors to ‘5a’ and it showed up correctly. So this is a good thing. What I haven’t tried is assigning the drive to a pool yet and give it a try.

Updated previous posting to remove -f

Good point!