linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>
To: NeilBrown <neilb@suse.de>
Cc: Piergiorgio Sartor <piergiorgio.sartor@nexgo.de>,
	Bernd Schubert <bernd.schubert@itwm.fraunhofer.de>,
	linux-raid@vger.kernel.org, Robert Buchholz <rbu@goodpoint.de>
Subject: Re: [PATCH 0/6] raid6check fixes
Date: Thu, 27 Jun 2013 22:49:00 +0200	[thread overview]
Message-ID: <20130627204900.GA2240@lazy.lzy> (raw)
In-Reply-To: <20130627142719.5ffbf0ce@notabene.brown>

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?

"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.

Thanks,

bye,

pg

> Having two blocks on different drives being bad might be cause for extra
> warnings, but it doesn't make any difference if they are in the same stripe
> or in different stripes.
> 
> i.e. the chunksize should be used only as part of the calculation to work out
> the layout at any particular place in the array.  It should not be used as a
> unit for reading and writing data.
> 
> In anyone feels like addressing that issue, I would be very receptive to
> patches :-)
> 
> NeilBrown



-- 

piergiorgio

  reply	other threads:[~2013-06-27 20:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-18  9:09 [PATCH 0/6] raid6check fixes Bernd Schubert
2013-06-18  9:09 ` [PATCH 1/6] raid6check: Fix build of raid6check Bernd Schubert
2013-06-18  9:09 ` [PATCH 2/6] Makefile: Allow the user to pass EXTRA_CFLAGS Bernd Schubert
2013-06-19  0:07   ` NeilBrown
2013-06-19  9:48     ` Bernd Schubert
2013-06-24  7:01       ` NeilBrown
2013-06-18  9:09 ` [PATCH 3/6] raid6check: Fix memory leaks detected by valgrind Bernd Schubert
2013-06-18  9:09 ` [PATCH 4/6] raid6check: Use enums for repair type Bernd Schubert
2013-06-18  9:09 ` [PATCH 5/6] raid6check: Fix compiler warnings Bernd Schubert
2013-06-18  9:09 ` [PATCH 6/6] raid6check: Check return value of lseek64() Bernd Schubert
2013-06-18 17:16 ` [PATCH 0/6] raid6check fixes Piergiorgio Sartor
2013-06-19  0:08 ` NeilBrown
2013-06-20 16:16   ` Piergiorgio Sartor
2013-06-24  7:04     ` NeilBrown
2013-06-24 17:10       ` Piergiorgio Sartor
2013-06-24 23:54         ` NeilBrown
2013-06-25 16:46           ` Piergiorgio Sartor
2013-06-27  4:27             ` NeilBrown
2013-06-27 20:49               ` Piergiorgio Sartor [this message]
2013-06-27 21:12                 ` NeilBrown
2013-06-28 17:46                   ` Piergiorgio Sartor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130627204900.GA2240@lazy.lzy \
    --to=piergiorgio.sartor@nexgo.de \
    --cc=bernd.schubert@itwm.fraunhofer.de \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=rbu@goodpoint.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).