From: Kent Overstreet <koverstreet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
To: Pierre Beck <debian-bugs-MZZvbRqs/9F0RdzJJlgK+g@public.gmane.org>
Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Loosing transactions
Date: Tue, 29 Jan 2013 11:01:33 -0800 [thread overview]
Message-ID: <20130129190133.GL26407@google.com> (raw)
In-Reply-To: <51068F01.9060000-MZZvbRqs/9F0RdzJJlgK+g@public.gmane.org>
On Mon, Jan 28, 2013 at 03:45:23PM +0100, Pierre Beck wrote:
>
> >We probably want to start by simplifying/narrowing it down a bit - we
> >can eliminate the possibility of the disk having anything to do with it
> >and just use the SSD by forcing everything to writeback mode:
> >
> >For that you'll want to disable both sequential bypass (echo 0 >
> >/sys/block/bcache/bcacheN/sequential_cutoff) and the congested
> >thresholds -
> >echo 0 > /sys/fs/bcache/<cache set>/congested_read_threshold_us,
> >echo 0 > /sys/fs/bcache/<cache set>/congested_write_threshold_us
> >
> >After that (assuming you're also in writeback mode) all writes will be
> >writeback writes until the device is more than half full of dirty data.
> >
> >Can you check if transactions are still getting lost in that setup? If
> >so (I kind of expect they will be) we may have to do a bit of
> >blktracing, but that'll really narrow down the possibilities.
> >
>
> Yes, the most recent transactions are still lost.
Think I figured out what's going on. Just had a chat with another kernel
dev and figured out the flaw in my logic :P
This is going to take some thought to fix, though it shouldn't be much
code. I'll let you know when I think I have a fix.
next prev parent reply other threads:[~2013-01-29 19:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-23 20:14 Loosing transactions Pierre Beck
[not found] ` <51004490.704-MZZvbRqs/9F0RdzJJlgK+g@public.gmane.org>
2013-01-24 23:35 ` Kent Overstreet
[not found] ` <20130124233559.GO26407-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2013-01-28 14:45 ` Pierre Beck
[not found] ` <51068F01.9060000-MZZvbRqs/9F0RdzJJlgK+g@public.gmane.org>
2013-01-29 19:01 ` Kent Overstreet [this message]
[not found] ` <20130129190133.GL26407-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2013-01-29 19:09 ` Kent Overstreet
[not found] ` <20130129190942.GM26407-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2013-01-29 20:16 ` Pierre Beck
[not found] ` <51082E02.7000908-MZZvbRqs/9F0RdzJJlgK+g@public.gmane.org>
2013-01-30 19:02 ` Kent Overstreet
[not found] ` <20130130190220.GS26407-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
2013-01-30 20:05 ` Pierre Beck
[not found] ` <51097D0A.6040204-MZZvbRqs/9F0RdzJJlgK+g@public.gmane.org>
2013-01-30 20:18 ` Kent Overstreet
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=20130129190133.GL26407@google.com \
--to=koverstreet-hpiqsd4aklfqt0dzr+alfa@public.gmane.org \
--cc=debian-bugs-MZZvbRqs/9F0RdzJJlgK+g@public.gmane.org \
--cc=linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/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.