W dniu 16.09.2016 o 11:16, Kent Overstreet pisze:

On Fri, Sep 16, 2016 at 11:02:10AM +0200, Marcin Mirosław wrote:

quoted

W dniu 16.09.2016 o 10:38, Kent Overstreet pisze:
[...]

quoted

I haven't yet tried randomly flipping the compression type at runtime, I'll try
that now...

Don't forget changing other options, simply changing compression type I
tested some times ago and it worked;) I think that also heavy writes
while making changes are important.

Yeah, I think you're right about heavy writes - the one other bug remotely like
this that's been reported was an intermittent deadlock under heavy write load.

But "heavy write workload" describes a lot of the tests I already have, so I'm
not sure what I'm missing. Argh.

I used rsync to make noise:) Ok, With netconsole's help I have:
[11055.485337] bcache (dm-11): journal replay done, 0 keys in 1 entries,
seq 3451
< now I'm starting rsync on earlier used fs, problem happened soon >
[11159.293119] Kernel panic - not syncing: stack-protector: Kernel stack
is corrupted in: ffffffffc095b021
[11159.293157] CPU: 0 PID: 30023 Comm: rsync Tainted: P           O
4.7.0-bcache+ #2
[11159.293166] Hardware name: .   .  /IP35 Pro XE(Intel P35-ICH9R), BIOS
6.00 PG 09/09/2008
[11159.293176]  0000000000000086
00000000414f6380
ffff88002814fae0
ffffffff812cbe0d
[11159.293537] Kernel Offset: disabled
[11159.296006] ---[ end Kernel panic - not syncing: stack-protector:
Kernel stack is corrupted in: ffffffffc095b021

New lines can be broken, I used tcpdump to catch messages.

Marcin