From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pierre Beck Subject: Re: Loosing transactions Date: Mon, 28 Jan 2013 15:45:23 +0100 Message-ID: <51068F01.9060000@pierre-beck.de> References: <51004490.704@pierre-beck.de> <20130124233559.GO26407@google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130124233559.GO26407-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> Sender: linux-bcache-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Kent Overstreet Cc: linux-bcache-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: linux-bcache@vger.kernel.org > 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//congested_read_threshold_us, > echo 0 > /sys/fs/bcache//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. Greetings, Pierre Beck