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: >> W dniu 16.09.2016 o 10:38, Kent Overstreet pisze: >> [...] >>> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
