Disk in parity slot is not biggest issue

[RT87]

Thanks a lot for the /dev and /mnt path clarification!

 

Okay, I see, btw also thx for that info! Is there some switch with which to tell unraid to NOT emulate a disk right away, but rather give errors on failed reads/writes first? That in combination with a "emulate failed disk" button would be a workaround to avoid disabling drives due to mere hickups.

 

Furthermore: If any drive becomes disabled, but it is not truly broken, i.e. such a hickup has occurred: Can Unraid "catch up" to writing the data (from the parity-data) to the (temporarily) disabled drive, or, if at any point in time any drive got "disabled", do I automatically have to rebuild the entire parity/disabled disk?

 

 

[trurl]

2 minutes ago, RT87 said:

Is there some switch

No, but if you don't have parity nothing can be emulated obviously.

 

3 minutes ago, RT87 said:

have to rebuild the entire parity/disabled disk?

yes

[trurl]

4 minutes ago, RT87 said:

Can Unraid "catch up" to writing the data

It has no way to distinguish the emulated parity bits from the others. They are just bits.

[RT87]

Quote

They are just bits.

makes sense.... although I guess with some form of bookkeeping on a separate drive it would work, but to be fair that's maybe a bit over the top :P.

 

I would still love a do-not-auto-emulate-drives option... would it make sense to put that into a feature request?

 

 

[JonathanM]

1 hour ago, RT87 said:

 

I would still love a do-not-auto-emulate-drives option... would it make sense to put that into a feature request?

Only if you can lay out exactly what would need to change at a basic level, and how it would effect current operation.

 

The parity function is in such a low level of unraid, and so much is built on it, it would take a major benefit case to even consider putting in all the labor to make and verify the changes. I don't see it happening unless the possible upside would be extremely valuable.

 

On the face of it, a setting that would appear to crash the server (all operations would have to freeze immediately on errors) is not something that would be seen as a benefit, but if you can articulate it compellingly, go for it.

[trurl]

The whole point of RAID (and Unraid's similar parity) is to allow things to continue to operate when a disk fails, without data loss.

[RT87]

Quote

The whole point of RAID (and Unraid's similar parity) is to allow things to continue to operate when a disk fails, without data loss.

Yes of course, but to be fair: Options always have a positive value. If I don't want this behaviour, I simply untick the corresponding box...

 

Quote

On the face of it, a setting that would appear to crash the server (all operations would have to freeze immediately on errors) is not something that would be seen as a benefit, but if you can articulate it compellingly, go for it.

At least all array operations would have to stop immediately, yes. If you have a cache, that could continue working or at least shutdown gracefully.

This option might also be for the super cautious, who are less interested in reducing or eliminating off-time, but rather in avoiding data loss as much as possible. But I agree, if this needs a significant rework, it won't get implemented. Oh well, worth a shot, that's why I asked whether it would make sense.

 

Thanks guys!

 

Since I got a little side-tracked (mea culpa, btw!) with lots of other interesting stuff: Does anyone know of any way to get my parity working, at least for the moment using USB? I see your points regarding its weaknesses, but I will not be able to switch to a better solution right away, because I have no low-power components for a "true" server lying around, and thus I would first have to read up on that, order all the stuff and put it together XP.