From: Timothy Pearson <email@example.com> To: Qu Wenruo <firstname.lastname@example.org> Cc: linux-btrfs <email@example.com> Subject: Re: Unusual crash -- data rolled back ~2 weeks? Date: Sun, 10 Nov 2019 04:02:11 -0600 (CST) Message-ID: <825354711.177110.1573380131178.JavaMail.firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> ----- Original Message ----- > From: "Qu Wenruo" <firstname.lastname@example.org> > To: "Timothy Pearson" <email@example.com> > Cc: "linux-btrfs" <firstname.lastname@example.org> > Sent: Sunday, November 10, 2019 1:45:14 AM > Subject: Re: Unusual crash -- data rolled back ~2 weeks? > On 2019/11/10 下午3:18, Timothy Pearson wrote: >> >> >> ----- Original Message ----- >>> From: "Qu Wenruo" <email@example.com> >>> To: "Timothy Pearson" <firstname.lastname@example.org> >>> Cc: "linux-btrfs" <email@example.com> >>> Sent: Sunday, November 10, 2019 6:54:55 AM >>> Subject: Re: Unusual crash -- data rolled back ~2 weeks? >> >>> On 2019/11/10 下午2:47, Timothy Pearson wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> From: "Qu Wenruo" <firstname.lastname@example.org> >>>>> To: "Timothy Pearson" <email@example.com>, "linux-btrfs" >>>>> <firstname.lastname@example.org> >>>>> Sent: Saturday, November 9, 2019 9:38:21 PM >>>>> Subject: Re: Unusual crash -- data rolled back ~2 weeks? >>>> >>>>> On 2019/11/10 上午6:33, Timothy Pearson wrote: >>>>>> We just experienced a very unusual crash on a Linux 5.3 file server using NFS to >>>>>> serve a BTRFS filesystem. NFS went into deadlock (D wait) with no apparent >>>>>> underlying disk subsystem problems, and when the server was hard rebooted to >>>>>> clear the D wait the BTRFS filesystem remounted itself in the state that it was >>>>>> in approximately two weeks earlier (!). >>>>> >>>>> This means during two weeks, the btrfs is not committed. >>>> >>>> Is there any hope of getting the data from that interval back via btrfs-recover >>>> or a similar tool, or does the lack of commit mean the data was stored in RAM >>>> only and is therefore gone after the server reboot? >>> >>> If it's deadlock preventing new transaction to be committed, then no >>> metadata is even written back to disk, so no way to recover metadata. >>> Maybe you can find some data written, but without metadata it makes no >>> sense. >> >> OK, I'll just assume the data written in that window is unrecoverable at this >> point then. >> >> Would the commit deadlock affect only one btrfs filesystem or all of them on the >> machine? I take it there is no automatic dmesg spew on extended deadlock? >> dmesg was completely clean at the time of the fault / reboot. > > It should have some kernel message for things like process hang for over > 120s. > If you could recover that, it would help us to locate the cause. > > Normally such deadlock should only affect the unlucky fs which meets the > condition, not all filesystems. > But if you're unlucky enough, it may happen to other filesystems. > > Anyway, without enough info, it's really hard to say. I was able to retrieve complete logs from the kernel for the entire time period. The BTRFS filesystem was online resized five days before the last apparent filesystem commit. Immediately after resize, a couple of csum errors were thrown for a single inode on the resized filesystem, though this was not detected at the time. The underlying hardware did not experience a fault at any point and is passing all diagnostics at this time. Intriguingly, there are a handful of files accessible from after the last known good filesystem commit (Oct. 29), but the vast majority are simply absent. At this point I'm more interested in making sure this type of event does not happen in the future than anything else. At no point did the kernel print any type of stack trace or deadlock warning. I'm starting to wonder if we hit a bug in the online resize path, but am just guessing at this point. The timing is certainly very close / coincidental. Thanks!
next prev parent reply index Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-09 22:33 Timothy Pearson 2019-11-09 22:48 ` Timothy Pearson 2019-11-10 3:38 ` Qu Wenruo 2019-11-10 6:47 ` Timothy Pearson 2019-11-10 6:54 ` Qu Wenruo 2019-11-10 7:18 ` Timothy Pearson 2019-11-10 7:45 ` Qu Wenruo 2019-11-10 7:48 ` Timothy Pearson 2019-11-10 10:02 ` Timothy Pearson [this message] 2019-11-10 20:10 ` Zygo Blaxell 2019-11-11 23:28 ` Timothy Pearson 2019-11-11 23:33 ` Timothy Pearson 2019-11-12 11:30 ` Chris Murphy 2019-11-10 8:04 ` Andrei Borzenkov
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 \ --in-reply-to=825354711.177110.1573380131178.JavaMail.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 public-inbox-index linux-btrfs Example config snippet for mirrors 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.git