verify retry count

I was running verify on a big array last week and I got a parity error. Sometimes hard drives get bad sectors but they can be relocated. So I did a copy of all the files involved to a temp directory (and then removed them) to allow the drive to relocate the bad sector(s) if possible. Looking at the S.M.A.R.T settings in all the drives, there was a new relocated block count in one of them. Then ran verify again and this time it completed successfully.
It looks like verify doesn't retry a parity error. Could it retry a few times, or even better, can there be a retry count variable where we can tell verify how many times to retry a calculation before failing it? It will be also good if it prints a warning every time there's a retry.

This message was edited 1 time. Last update was at 17/07/2008 23:27:48

This is an interesting feature request.
It makes plenty of sense though with a long running process like the verify task.

I don't think retrying will do much good.
Once a sector is bad, it is bad.
What could be useful would be to pause the process, alert the user, then the user could resume (with an intelligent rollback) if he thinks the issues has been resolved or abort.

Hello Brahim, any news on making FlexRaid Basic open source? I would love to implement this feature myself.

I don't think retrying will do much good.
Once a sector is bad, it is bad.

The problem is that there is no industry standard as to what a bad sector is... For example, a drive targeted for workstations will retry several thousand times before marking the sector bad. It could take minutes, instead of a fraction of a second, to read just one sector. A drive targeted to the server market will just retry for a few seconds before giving up. That's because such drive will most likely be part of a hardware based RAID and the controller could mark the drive as bad if it takes too long to report a success or failure. In my case I just had to read the file a couple of times. Eventually the drive got a successful read, marked the block bad, and moved the data to another block in the free list.

As I had stated before, retrying makes sense.
I will work on adding the option to retry.

Right now, the fight is between maintaining the balance between features and performance.
So many things could be done if performance wasn't a major issue.

I need to reach a certain point before I open up the code.
Mostly, there are certain things with FlexRAID Live! I need to finish up first.

In that case please don't let me distract you. I thought that FlexRaid Basic and Live! had completely different codebases since you referred to Basic as a proof of concept. But if adding features at this point will complicate your good work please don't worry about it. I really like FlexRaid Basic, so I can wait for it to become open source!

spiffyrex wrote:In that case please don't let me distract you. I thought that FlexRaid Basic and Live! had completely different codebases since you referred to Basic as a proof of concept. But if adding features at this point will complicate your good work please don't worry about it. I really like FlexRaid Basic, so I can wait for it to become open source!

They do have different code bases.
It is just that opening up the code bases will require some strict management on my part.

This won't be a free code to go do whatever you please, but rather an open code asking for improvements (if that makes sense).
Basically, if you have nothing to add to FlexRAID, you will never see the code (if I can help it).