Re: I think he's dead, Jim

[Chris Murphy <lists@colorremedies.com>]

On Mon, May 18, 2020 at 2:51 PM Justin Engwer <justin@mautobu.com> wrote:
>
> Hi,
>
> I'm hoping to get some (or all) data back from what I can only assume
> is the dreaded write hole. I did a fairly lengthy post on reddit that
> you can find here:
> https://old.reddit.com/r/btrfs/comments/glbde0/btrfs_died_last_night_pulling_out_hair_all_day/
>
> TLDR; BTRFS keeps dropping to RO. System sometimes completely locks up
> and needs to be hard powered off because of read activity on BTRFS.
> See reddit link for actual errors.

Almost no one will follow the links. You've got a problem, which is
unfortunate, but you're also asking for help so you kinda need to make
it easy for readers to understand the setup instead of having to go
digging for it elsewhere. And also it's needed for archive
searchability, which an external reference doesn't provide.

a. kernel and btrfs-progs version; ideally also include some kernel
history for this file system
b. basics of the storage stack: what are the physical drives, how are
they connected,
c. if VM, what's the hypervisor, are the drives being passed through,
what caching mode
d. mkfs command used to create; or just state the metadata and data
profiles; or paste 'btrfs fi us /mnt'
e. ideally a complete dmesg (start to finish, not snipped) at the time
of the original problem, this might be the prior boot; it's probably
too big to attach to the list so in that case nextcloud, dropbox,
pastebin, etc.
f. a current dmesg for the mount failure
g. btrfs check --readonly /dev/


I thought we had a FAQ item with what info we wanted reported to the
list, but I can't find it.


Thanks,

-- 
Chris Murphy