On Thu, 27 Jun 2013 22:49:00 +0200 Piergiorgio Sartor
[off-list ref] wrote:

On Thu, Jun 27, 2013 at 02:27:19PM +1000, NeilBrown wrote:
[...]

quoted

I've just had a little look at raid6test - because some of the selftests were
failing.

The default output is rather verbose.  Verbose output can be good, but not as
the default I think.

However, more importantly, it pays too much heed to the chunksize.

If the start of one chunk on drive X is bad, and the end of a corresponding
chunk on drive Y is bad, then it will complain that it cannot figure out the
problem.
It shouldn't do that.  It shouldn't even look at whole chunks at a time.

It should look at blocks.  Maybe 512bytes or 1K or 4K any of those would do.
Then for each block it should figure out if there is a problem, and maybe
auto-fix it.

Hi Neil,

thanks for the feedback.

I checked "mdadm" man page and it states that the chunk
size is always a multiple of 4K (and a power of 2).
I assume this is correct, so I would suggest 4K as
block size. Also because of SSD and many HDD which
are already 4K.

What do you think?

Does it seem reasonable to you?

Yes, using 4K blocks is perfectly reasonable.

"raid6check" is processing and collecting statistics
"per byte", I assume it should not need a big architectural
change in order to fit 4K.

About the verbosity, I know, this was already discussed.
My idea was to reduce it, once the other code stabilize.

Fair enough.  I was thinking in the context of making raid6check part of the
default install.  I wouldn't want to do that until it was more "user
friendly".  I also wouldn't want to do it until he code had stabilized.  So
your idea fits perfectly.

Thanks,
NeilBrown