Re: [PATCH 0/6] raid6check fixes

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

On Thu, 27 Jun 2013 22:49:00 +0200 Piergiorgio Sartor
<piergiorgio.sartor@nexgo.de> wrote:

> On Thu, Jun 27, 2013 at 02:27:19PM +1000, NeilBrown wrote:
> [...]
> > 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]