From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tim@buttersideup.com>
Received: from relay1.allsecuredomains.com (relay1.allsecuredomains.com
 [78.47.251.4])
 (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (No client certificate requested)
 by mail.server123.net (Postfix) with ESMTPS
 for <dm-crypt@saout.de>; Mon, 16 May 2016 18:08:37 +0200 (CEST)
References: <044401d1a958$ea7ef4e0$bf7cdea0$@codenest.com>
From: Tim Small <tim@buttersideup.com>
Message-ID: <5739F07A.5090608@buttersideup.com>
Date: Mon, 16 May 2016 17:08:27 +0100
MIME-Version: 1.0
In-Reply-To: <044401d1a958$ea7ef4e0$bf7cdea0$@codenest.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [dm-crypt] bcache gets stuck flushing writeback cache when used
 in combination with LUKS/dm-crypt and non-default bucket size
List-Id: <dm-crypt.saout.de>
List-Unsubscribe: <http://www.saout.de/mailman/options/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=unsubscribe>
List-Archive: <http://www.saout.de/pipermail/dm-crypt/>
List-Post: <mailto:dm-crypt@saout.de>
List-Help: <mailto:dm-crypt-request@saout.de?subject=help>
List-Subscribe: <http://www.saout.de/mailman/listinfo/dm-crypt>,
 <mailto:dm-crypt-request@saout.de?subject=subscribe>
To: James Johnston <johnstonj.public@codenest.com>, 'Kent Overstreet' <kent.overstreet@gmail.com>, 'Alasdair Kergon' <agk@redhat.com>, 'Mike Snitzer' <snitzer@redhat.com>
Cc: linux-bcache@vger.kernel.org, dm-devel@redhat.com, dm-crypt@saout.de

On 08/05/16 19:39, James Johnston wrote:
> I've run into a problem where the bcache writeback cache can't be flushed to
> disk when the backing device is a LUKS / dm-crypt device and the cache set has
> a non-default bucket size.  Basically, only a few megabytes will be flushed to
> disk, and then it gets stuck.  Stuck means that the bcache writeback task
> thrashes the disk by constantly reading hundreds of MB/second from the cache set
> in an infinite loop, while not actually progressing (dirty_data never decreases
> beyond a certain point).

> [...]

> The situation is basically unrecoverable as far as I can tell: if you attempt
> to detach the cache set then the cache set disk gets thrashed extra-hard
> forever, and it's impossible to actually get the cache set detached.  The only
> solution seems to be to back up the data and destroy the volume...

You can boot an older kernel to flush the device without destroying it
(I'm guessing that's because older kernels split down the big requests
which are failing on the 4.4 kernel).  Once flushed you could put the
cache into writethrough mode, or use a smaller bucket size.

Tim.