Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Christian Theune <ct@flyingcircus.io>, linux-btrfs@vger.kernel.org
Subject: Re: Downgrading kernel 4.9 to 4.4 with space_cache=v2 enabled?
Date: Thu, 23 Feb 2017 07:34:06 -0500	[thread overview]
Message-ID: <029c96aa-9c1e-f12c-8b63-4e4485428c67@gmail.com> (raw)
In-Reply-To: <BB064A3C-6F5C-4490-80A6-F42BEFAA945A@flyingcircus.io>

On 2017-02-23 05:51, Christian Theune wrote:
> Hi,
>
> not sure whether it’s possible, but we tried space_cache=v2 and obviously after working fine in staging it broke in production. Or rather: we upgraded from 4.4 to 4.9 and enabled the space_cache. Our production volume is around 50TiB usable (underlying HW Raid 6).
>
> The machine crashes silently every 15 hours or so and takes _ages_ to reboot. It current is stuck trying to mount the local filesystems and I guess btrfs is doing something, but I don’t have shell access yet.
>
> I’m wondering whether we can downgrade by booting back into 4.4 or will this break things even further? (We’ve had some unpleasant surprises with FS’ in the last months, so I thought I’d rather ask.)
If it has a v2 free space cache and was mounted on a kernel newer than 
(I think) 4.8, it almost certainly won't mount on a 4.4 kernel.  The 
free-space-tree code got added in 4.5, and there was an incompatible 
filesystem flag added more recently to mark filesystems which are 
unaffected by a bug in the original implementation.  That flag gets set 
automatically on kernels that include the code to fix the bug's effects 
on the FS, which IIRC includes 4.9 kernels.

That said, if you can get it to mount at all on the 4.9 kernel, you can 
probably convert it back by mounting with -o clear_cache,space_cache=v1. 
  I'm saying probably in this case because it may be more than just the 
v2 space cache that's messed up, and if there's other corruption in the 
FS, you'll still see issues.  If it's just the free space cache though, 
adding those two options to the mount options (and removing 
space_cache=v2) should let it mount much more quickly, and you should 
see some above-average disk activity for a while, but afterwards you 
should be able to mount it on the 4.4 kernel again.


  reply	other threads:[~2017-02-23 12:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-23 10:51 Downgrading kernel 4.9 to 4.4 with space_cache=v2 enabled? Christian Theune
2017-02-23 12:34 ` Austin S. Hemmelgarn [this message]
     [not found]   ` <71958378-5AB4-4E66-8F54-60215141D1BB@flyingcircus.io>
2017-02-23 13:19     ` Christian Theune
2017-02-23 13:38       ` Austin S. Hemmelgarn
2017-02-24 18:35         ` Omar Sandoval
2017-02-24  0:54 ` Qu Wenruo
2017-02-24 12:23   ` Austin S. Hemmelgarn
2017-02-24 18:34     ` Omar Sandoval

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=029c96aa-9c1e-f12c-8b63-4e4485428c67@gmail.com \
    --to=ahferroin7@gmail.com \
    --cc=ct@flyingcircus.io \
    --cc=linux-btrfs@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