public inbox for linux-bcache@vger.kernel.org
 help / color / mirror / Atom feed
From: Kai Krakow <hurikhan77@gmail.com>
To: linux-bcache@vger.kernel.org
Subject: Re: journal replay at each boot problematic?
Date: Wed, 29 Mar 2017 19:59:51 +0200	[thread overview]
Message-ID: <20170329195951.604ad133@jupiter.sol.kaishome.de> (raw)
In-Reply-To: 20170329195257.0e11c5e9@jupiter.sol.kaishome.de

Am Wed, 29 Mar 2017 19:52:57 +0200
schrieb Kai Krakow <hurikhan77@gmail.com>:

> Am Wed, 29 Mar 2017 14:27:11 +0200
> schrieb Clemens Eisserer <linuxhippy@gmail.com>:
> 
> > 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.

Addendum: Maybe try "btrfs sync"...

> > 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.

      reply	other threads:[~2017-03-29 18:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-27 11:33 journal replay at each boot problematic? Clemens Eisserer
2017-03-27 20:51 ` Kai Krakow
2017-03-29 12:27   ` Clemens Eisserer
2017-03-29 17:52     ` Kai Krakow
2017-03-29 17:59       ` Kai Krakow [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170329195951.604ad133@jupiter.sol.kaishome.de \
    --to=hurikhan77@gmail.com \
    --cc=linux-bcache@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox