From: Robert White <firstname.lastname@example.org> To: Chris Murphy <email@example.com>, Lee Fleming <firstname.lastname@example.org>, Btrfs BTRFS <email@example.com> Subject: Re: Unbootable root btrfs Date: Sat, 18 May 2019 04:39:55 +0000 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <CAJCQCtQhrh8VBKe11gQUt5BSuWCsDQUdt_Q4a4opnAYE5XoEVQ@mail.gmail.com> On 5/18/19 4:06 AM, Chris Murphy wrote: > On Fri, May 17, 2019 at 2:18 AM Lee Fleming <email@example.com> 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 conditions. None of this my apply to OP, but it's the thing I'd check before before digging too far.
next prev parent 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] ` <CAKS=YrMB6SNbCnJsU=rD5gC6cR5yEnSzPDax5eP-VQ-UpzHvAg@mail.gmail.com> 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: 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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.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
Linux-BTRFS Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-btrfs/0 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/ https://lore.kernel.org/linux-btrfs \ email@example.com firstname.lastname@example.org public-inbox-index linux-btrfs Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-btrfs AGPL code for this site: git clone https://public-inbox.org/ public-inbox