On Tue, 21 Jan 2020 at 14:05, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > > > > On 2020/1/21 上午10:58, Robbie Smith wrote: > [...] > >> > >> Really hard to say, there are at least 3 things related to this problem. > >> > >> - Btrfs itself > >> - Hibernation > >> - Dm-crypt (less possible) > >> > >> For btrfs, if you have used kernel between version v5.2.0 and v5.2.15, > >> then it's possible the fs is already corrupted but not detected. > >> > >> For the hibernation part, Linux is not the best place to utilize it for > >> the first place. > >> (My ThinkPad X1 Carbon 6th suffers from hibernation, so I rarely use > >> suspension/hiberation) > >> > >> Since linux development is mostly server oriented, such daily consumer > >> operation may not be that well tested. > >> > >> Things like Windows updating certain firmware could break the controller > >> behavior and cause unexpected behavior. > >> > >> So my personal recommendation is, to avoid hibernation/suspension, use > >> Windows as little as possible. > >> > >> Thanks, > >> Qu > > > > Suspension works flawlessly for me, and hibernation usually does as > > well. The one thing that has happened both times I've had a failure > > has been something weird with the power: first time was a static shock > > from walking on carpet and then touching the laptop, second time was > > the BIOS reporting a wattage error with the charger. > > This doesn't look correct for ThinkPad T series machine... > > > > > I tried mounting the FS from a live USB and the mount said: "can't > > read superblock on /dev/mapper/cryptroot" in addition to the transid > > failures. Should I try running a `btrfs check --repair`? At this point > > I'm pretty much resigned to reinstalling today, so I can't make things > > any worse, can I? > > Full output please. I can't get the output from that mount run as it's lost in the shell history. Attempting to mount now does nothing and just spits out: > # mount -t btrfs -o ro,usebackuproot /dev/mapper/cryptroot /mnt/cryptroot > [dmesg timestamp] BTRFS error (device dm-0): parent transid verify failed on 223452889088 wanted 144360 found 144376 > [dmesg timestamp] BTRFS error (device dm-0): parent transid verify failed on 223452889088 wanted 144360 found 144376 btrfs check prints the UUID, and that's it. > # btrfs check /dev/mapper/cryptroot > Opening filesystem to check... > Checking filesystem on /dev/mapper/cryptroot > UUID: 25ac1f63-5986-4eb8-920f-ed7a5354c076 Attempting a dry-run of btrfs restore gave me these messages. The fact that it can read some files and find my /home subvolume gives me some hope. > # btrfs restore -D /dev/mapper/cryptroot /mnt/restore > This is a dry-run, no files are going to be restored > We have looped trying to restore files in /@home/robbie/.cache/chromium/Default/Code Cache/js too many times to be making progress, stopping > We have looped trying to restore files in /@home/robbie/.cache/chromium/Default/Cache too many times to be making progress, stopping > We have looped trying to restore files in /@home/robbie/.cache/chromium/Profile 1/Cache too many times to be making progress, stopping > We have looped trying to restore files in /@home/robbie/.cache/chromium/Profile 2/Code Cache/js too many times to be making progress, stopping > We have looped trying to restore files in /@home/robbie/.cache/chromium/Profile 2/Cache too many times to be making progress, stopping > We have looped trying to restore files in /@home/robbie/.cache/thumbnails/large too many times to be making progress, stopping > We have looped trying to restore files in /@home/robbie/.cache/mozilla/firefox/eedh8ma4.default-release/cache2/entries too many times to be making progress, stopping > We have looped trying to restore files in /@home/robbie/.config/discord/Cache too many times to be making progress, stopping I'm going to go get myself a new external drive, reformat it as ext4 or something (what would be the best filesystem to use?—they always come out of the box as NTFS for Windows), and then try restoring my filesystem to that. Maybe I can recover things before attempting a `btrfs check --repair`. Worst case scenario then is that I have a few corrupted files on a spare disk. > > > > > I've also used kernel between version 5.2.0 and 5.2.15 on both my > > machines, so does that mean there's a risk of undetected disk errors > > on my desktop as well? > > It's possible. > > > I don't have backups of my backups, and all my > > drives use BTRFS because I like the subvolume/snapshot features. I > > also don't have a backup of my music/video library because I don't > > have another 5 TB HDD. > > You can just run "btrfs check" from a liveUSB to check if the fs is OK. > > Thanks, > Qu >
