Am Wed, 29 Mar 2017 14:27:11 +0200 schrieb Clemens Eisserer <linuxhippy@xxxxxxxxx>: > Hi Kai, > > > As far as the docs tell, bcache is designed to shut down unclean. So > > this is expected behavior in write-back mode. > > Yes, I also read it - but since I got a few btrfs fs errors when > running btrfs check (mostly space-cache related) I became a bit > alarmed. > As all csums are ok, so I don't think the backing/caching devices are > corrupt in any way. This is probably related to btrfs not closed properly or some bug in an older kernel. Space cache problems can usually be safely ignored as long as the kernel detects them. But maybe ask about this in the btrfs list. I'm pretty sure that is related to your shutdown procedure and not to bcache. I don't see such messages here without special workarounds in the shutdown procedure, however, I'm using initramfs created by dracut. It properly unmounts btrfs. > > To cleanly detach a bcache, you would need to first put it in > > write-through or write-around mode and wait for write-back to > > finish. In turn, this mode should also avoid these messages at > > boot. > > This is exactly what I do now before each shutdown: switch to > writethrough and wait in a bash-loop until state="clean" - sorrounded > by two calls to sync. I don't think this is necessary. Just ensure that the FS is umounted or at least RO mounted, sync, and ensure that all storage buffers are flushed (SCSI, SATA, whatever). Btrfs may lazily still write data even in the RO mounted mode. This may be your problem. Bcache may even prevent further evil here because of its always-unclean writeback behavior. > However, I still get the journal replay messages at bootup: > > [ 2.590615] bcache: bch_journal_replay() journal replay done, 827 > keys in 37 entries, seq 145717 Do you properly close the FS before shutting down, i.e. unmount (and not only remount RO), and flush the storage layer? -- Regards, Kai Replies to list-only preferred. -- 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
