From: Mykola Golub <mgolub@mirantis.com>
To: Gregory Farnum <gfarnum@redhat.com>
Cc: ceph-devel <ceph-devel@vger.kernel.org>
Subject: Re: osd: new pool flags: noscrub, nodeep-scrub
Date: Fri, 11 Sep 2015 15:47:05 +0300 [thread overview]
Message-ID: <20150911124704.GB12899@gmail.com> (raw)
In-Reply-To: <CAJ4mKGZPXnH+z=aBp7vLY35pj4JXq6c_Sq1PFknWj5y0fs2-zQ@mail.gmail.com>
On Fri, Sep 11, 2015 at 11:08:29AM +0100, Gregory Farnum wrote:
> On Fri, Sep 11, 2015 at 7:42 AM, Mykola Golub <mgolub@mirantis.com> wrote:
> > Hi,
> >
> > I would like to add new pool flags: noscrub and nodeep-scrub, to be
> > able to control scrubbing on per pool basis. In our case it could be
> > helpful in order to disable scrubbing on cache pools, which does not
> > work well right now, but I can imagine other scenarios where it could
> > be useful too.
>
> Can you talk more about this? It sounds to me like maybe you dislike
> the performance impact of scrubbing, but it's fairly important in
> terms of data integrity. I don't think we want to permanently disable
> them. A corruption in the cache pool isn't any less important than in
> the backing pool — it will eventually get flushed, and it's where all
> the reads will be handled!
I was talking about this:
http://tracker.ceph.com/issues/8752
(false-negative on a caching pool). Although the best solution is
definitely to fix the bug, I am not sure it will be resolved soon (the
bug is open for a year). Still these false-negatives are annoying, as
they complicate monitoring for real inconsistent pgs. In this case I
might want to disable periodic scrub for caching pools, as a
workaround (I could do scrub for them manually though).
This might be not the best example where these flags could be helpful
(I just came to the idea when thinking about a workaround for that
problem, and this looked useful to me in general). We already have
'ceph osd set no[deep-]scrub', and users use it to temporary resolve
high I/O load. Being able to do this per pool looks useful too.
You might have pools of different importance for you, and disabling
scrub for some of them might be ok.
--
Mykola Golub
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-09-11 12:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-11 6:42 osd: new pool flags: noscrub, nodeep-scrub Mykola Golub
2015-09-11 10:08 ` Gregory Farnum
2015-09-11 12:47 ` Mykola Golub [this message]
2015-09-11 12:59 ` Sage Weil
2015-09-11 13:11 ` Sebastien Han
2015-09-11 13:27 ` Wido den Hollander
2015-09-11 13:24 ` Mykola Golub
2015-09-11 13:44 ` Andrey Korolyov
2015-09-15 5:48 ` Mykola Golub
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=20150911124704.GB12899@gmail.com \
--to=mgolub@mirantis.com \
--cc=ceph-devel@vger.kernel.org \
--cc=gfarnum@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.