Linux-BTRFS Archive on
 help / color / Atom feed
From: Robert White <>
To: Chris Murphy <>,
	Lee Fleming <>,
	Btrfs BTRFS <>
Subject: Re: Unbootable root btrfs
Date: Sat, 18 May 2019 04:39:55 +0000
Message-ID: <> (raw)
In-Reply-To: <>

On 5/18/19 4:06 AM, Chris Murphy wrote:
> On Fri, May 17, 2019 at 2:18 AM Lee Fleming <> wrote:
>> I didn't see that particular warning. I did see a warning that it could cause damage and should be tried after trying some other things which I did. The data on this drive isn't important. I just wanted to see if it could be recovered before reinstalling.
>> There was no crash, just a reboot. I was setting up KVM and I rebooted into a different kernel to see if some performance problems were kernel related. And it just didn't boot.
> OK the corrupted Btrfs volume is a guest file system?

Was the reboot a reboot of the guest instance or the host? The reboot of 
the host can be indistinguishable from a crash to the guest file system 
images if shutdown is taking a long time. That megear fifteen second gap 
between SIGTERM and SIGKILL can be a real VM killer even in an orderly 
shutdown. If you don't have a qemu shutdown script in your host 
environment then every orderly shutdown is a risk to any running VM.

The question that comes to my mind is to ask what -blockdev and/or 
-drive parameters you are using? Some of the combinations of features 
and flags can, in the name of speed, "helpfully violate" the necessary 
I/O orderings that filesystems depend on.

So if the crash kills qemu before qemu has flushed and completed a 
guest-system-critical write to the host store you've suffered a 
corruption that has nothing to do with the filesystem code base.

So, for example, you shutdown your host system. I sends SIGTERM to qemu. 
The guest system sends SIGTERM to its processes. The guest is still 
waiting its nominal 15 seconds, when the host evicts it from memory with 
a SIGKILL because it's 15 second timer started sooner.

(15 seconds is the canonical time from my UNIX days, I don't know what 
the real times are for every distribution.)

Upping the caching behaviours for writes can be just as deadly in some 

None of this my apply to OP, but it's the thing I'd check before before 
digging too far.

  reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 10:36 Lee Fleming
2019-05-16 21:39 ` Chris Murphy
     [not found]   ` <>
2019-05-18  4:06     ` Chris Murphy
2019-05-18  4:39       ` Robert White [this message]
2019-05-18 19:28         ` Chris Murphy
2019-05-18 19:43           ` Lee Fleming

Reply instructions:

You may reply publically 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:

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

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-BTRFS Archive on

Archives are clonable:
	git clone --mirror linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ \
	public-inbox-index linux-btrfs

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox