On Thu, 27 Jun 2013 22:49:00 +0200 Piergiorgio Sartor <piergiorgio.sartor@xxxxxxxx> 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:
signature.asc
Description: PGP signature
