One missing device = fs not detected; upgrade things first?

[Andy Smith <andy@strugglers.net>]

Hi,

I cleanly shut down a machine and powered it off, then upon powering
up two things happened.

Firstly, one of the drives no longer responds or registers with the
OS in any way. As in there;s no device node for it and nothing in
the kernel logs.

Secondly, the btrfs filesystem that is spread across 7 of the
drives (including the missing one) also does not appear. As in,
Linux does not detect a btrfs filesystem on any of the remaining
drives, though the drives themselves appear to be there all fine.

Here's lsblk:

# lsblk
NAME                  MAJ:MIN RM   SIZE RO TYPE   MOUNTPOINT
sde                     8:64   0 931.5G  0 disk   
sdf                     8:80   0   1.8T  0 disk   
sdg                     8:96   0   1.8T  0 disk   
sdh                     8:112  0 931.5G  0 disk   
sdi                     8:128  0   1.8T  0 disk   
sdj                     8:144  0   2.7T  0 disk   

(I've omitted details of sd{a,b,c,d} as these are system drives and
not involved here.)

The btrfs fs is directly on those drives so it is expected that
lsblk shows no partitions, but it is not expected that it doesn't
show an fs.

Normally that would be e-k, but as I say, one appears dead. I am
wondering why this has affected my (raid1 profile for data and
metadata) btrfs filesystem though.

I did a "btrfs check" just to see what could be seen. That is still
progressing. It hasn't yet said anything other than a lot of
instances of "failed to load free space cache for block group
…":

# btrfs check -p /dev/sde
Opening filesystem to check...
Checking filesystem on /dev/sde
UUID: 472ee2b3-4dc3-4fc1-80bc-5ba967069ceb
[1/7] checking root items                      (0:07:57 elapsed, 3055030 items checked)
[2/7] checking extents                         (0:08:54 elapsed, 1334143 items checked)
failed to load free space cache for block group 15011172843520d, 1 items checked)
failed to load free space cache for block group 15012246585344
[lots more of that]
[3/7] checking free space cache                (0:05:04 elapsed, 4220 items checked)
[4/7] checking fs roots                        (0:51:38 elapsed, 126792 items checked)
[5/7] checking csums (without verifying data)  (0:13:45 elapsed, 2123139 items checked)

(still going)

If this completes without saying anything else of interest, should I
dare running it in repair mode? I do have backups.

If I should, then I know I should run this with more up to date
tools, because this is a Debian 10 machine with kernel
4.19.0-26-amd64 and btrfs-progs v4.20.1.

Should I build new btrfs-progs and then a new kernel and just boot
with those to see what happens, and then try the check --repair? Or
should I just build the new kernel and see what that makes of the
devices first, then build new btrfs-tools if I am still to run
check?

I did try mount -odegraded but no btrfs superblock is found, so
there is something up besides the missing drive.

Thanks,
Andy