itimpi

The original error message you showed talked about /def/sdg rather than /dev/sdg. Maybe you just kept typing it wrong

It looks as though that disk may have dropped off-line. This could be a problem with the disk, but may be something else. When (if) you get the disk back online you can run a smartctl command to check SMART information. I would also check carefully all cabling to see that nothing has worked its way lose.

UnRAID does not support hot swapping of array drives while the array is started. However as long as your hardware + BIOS supports it there is no problem with hot swapping array drives with array stopped, or drives that are not part of the array at any time.

I do not think that has ever been part of the standard GUI. You probably got it via unMenu or Simple Features.

Both of mine are in PCIx16 slots

This card is definitely supported. I have two of them in my system and they work just fine. I think it may well be one of the most commonly used expansion cards with unRAID. My guess is that the drive is having problems. Whether it is the drive itself, or something like cabling or power is not clear.

I have seen the pre_clear script produce unexpected results if the disk goes off-line during the pre-clear process.

Those results look good. It is not at all unusual for sectors that were flagged as pending re-allocation actually turn out to be OK when they are next written. As long as they do not keep re-appearing I would not worry. The original failure that resulted in them could have been due to some outside factor. However it is worth keeping an eye on them.

The figure that tends to be most important is whether the count of Reallocated sectors are steady (ideally 0), and also that the Pending Sectors value is 0 after a pre-clear (uRAID cannot work error free with sectors Pending Reallocation). You mention using unRAID 4.7. However that cannot handle disks larger than 2TB so you need the 5.0 release if you have any of those. The 5.0 release is very close to going final so should be safe to use.

This works fine for me.

I wonder what is causing the memory release? If at that time the cached directory entries for cache_dirs are also getting flushed from memory that would explain the disks spinning up as now they actually have to be read to get the directory entries the next time cache_dirs attempts this.

Isn't that what I said (the username needs to all be lowercase)

I seem to vaguely remember that you can have a problem if the username used is not all lower case at the Linux level?

But doesn't it wipe the MBR on step 4 & 5? Why is it still corrupt(?)? No idea - I assume that the write or read of the MBR did not work as expected. Maybe Joe L. will see this thread and have further insights.

It is saying the MBR was not cleared, so I expect 10 failed (that WILL read back the MBR).

Is the price the same if we are not US based? I am interested in getting some from your next batch.

The risk is too high. So rather than risk someone's data, I have elected to not not add that option. Thanks for the feedback - I thought I would ask but I can understand your viewpoint. The emphasis has to be on minimizing any chance of losing data.. I guess in this case I always have the option of skipping the pre and post clear phases to speed things up if the disk has been tested via other methods. I guess the better thing to do is to do some early preparation work and have new/spare disks well in advance of needing it and doing using the preclear_disk.sh script to do a thorough stress test. However this requires some pre-planning - not always my strongest point

I have some 3TB disks that have had zeroes written to them using the manufacturers diagnostic tools. Is it possible to just write the unRAID cleared indicator to them? The -z option talks about zeroing out the MBR but not setting it up as though it has been cleared for unRAID purposes. If not, then perhaps a new option (such as -Z) could be added to allow for this could be added to the script?