----- Original Message ----- > From: "Qu Wenruo" <quwenruo.btrfs@xxxxxxx> > To: "Timothy Pearson" <tpearson@xxxxxxxxxxxxxxxxxxxxx> > Cc: "linux-btrfs" <linux-btrfs@xxxxxxxxxxxxxxx> > 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" <quwenruo.btrfs@xxxxxxx> >>> To: "Timothy Pearson" <tpearson@xxxxxxxxxxxxxxxxxxxxx> >>> Cc: "linux-btrfs" <linux-btrfs@xxxxxxxxxxxxxxx> >>> 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" <quwenruo.btrfs@xxxxxxx> >>>>> To: "Timothy Pearson" <tpearson@xxxxxxxxxxxxxxxxxxxxx>, "linux-btrfs" >>>>> <linux-btrfs@xxxxxxxxxxxxxxx> >>>>> 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!
