RAID1 array failed to read chunk root

["Aaron W. Swenson" <aaron@grandmasfridge.org>]

[-- Attachment #1: Type: text/plain, Size: 3317 bytes --]

After moving residences, I've finally got my computer setup to 
find the array failed to mount. When trying to mount the RAID 
array, I get:

	root # mount -o compress=lzo,noatime,degraded /dev/sdc 
	/srv
	mount: /srv: wrong fs type, bad option, bad superblock on 
	/dev/sdc, missing codepage or helper program, or other 
	error.
       	dmesg(1) may have more information after failed mount 
       system call.

And in dmesg I see:

	[394680.895543] BTRFS info (device sdd): using crc32c 
	(crc32c-generic) checksum algorithm
	[394680.895555] BTRFS info (device sdd): use lzo 
	compression, level 0
	[394680.895557] BTRFS info (device sdd): allowing degraded 
	mounts
	[394680.895558] BTRFS info (device sdd): disk space 
	caching is enabled
	[394680.895802] BTRFS error (device sdd): failed to read 
	chunk root
	[394680.895903] BTRFS error (device sdd): open_ctree 
	failed

Running the command:

	root # btrfs rescue chunk-recover -v /dev/sdd

Takes a few hours (there are eight 4 TB drives in the array). It 
selected three devices from the RAID1 array (I think it was sdc, 
sdd, and sde...but that bit got purged from the scrollback 
buffer), and ultimately resulted in:

	Invalid mapping for 17983143280640-17983143297024, got 
	23995541880832-23996615622656
	Couldn't map the block 17983143280640
	Couldn't read tree root
	open with broken chunk error
	Chunk tree recovery failed

Here's some stats about my machine:

# uname -a
Gentoo Linux martineau 6.1.28-gentoo #1 SMP Sat May 27 19:30:38 
EDT 2023 x86_64 Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz 
GenuineIntel GNU/Linux
# btrfs version
btrfs-progs v6.6.3

Here's a table of my drives (excludes new Seagate Ironwolf 4TB 
that's still in the packaging). All drives in Bay 1 and Bay 2 are 
a part of the same RAID1 array. The Crucial drive is an SSD that's 
setup in the boring typical fashion for a root drive. A couple 
have failed in the past, but I had been able to mount degraded and 
replace the failed drive. I should note, a couple of days ago it 
reported that /dev/sdg was missing (same experience I've had twice 
before), which is why I have the spare drive. Now, it isn't 
reporting anything about the drive.

| ID | Path 	| Bay | Slot | Make	| Model 
  | Size  |
|----+----------+-----+------+---------+---------------------------------------+-------|
|  1 | /dev/sda |   0 |	0 | Crucial | BX100 (CT250BX100SSD1) 
   | 250GB |
| 10 | /dev/sdc |   1 |	1 | Seagate | Constellation ES.3 
  (ST4000NM0033-9ZM) | 4TB   |
|  9 | /dev/sdb |   1 |	2 | Seagate | Constellation ES.3 
   (ST4000NM0033-9ZM) | 4TB   |
|  7 | /dev/sdi |   1 |	3 | Seagate | Constellation ES.3 
   (ST4000NM0033-9ZM) | 4TB   |
|  8 | /dev/sdh |   1 |	4 | Seagate | Ironwolf (ST4000VN008-2DR1) 
   | 4TB   |
|  5 | /dev/sdf |   2 |	1 | Seagate | Constellation ES.3 
   (ST4000NM0033-9ZM) | 4TB   |
|  6 | /dev/sdd |   2 |	2 | Seagate | Ironwolf (ST4000VN008-2DR1) 
   | 4TB   |
|  4 | /dev/sdg |   2 |	3 | Seagate | Constellation ES.3 
   (ST4000NM0033-9ZM) | 4TB   |
|  3 | /dev/sde |   2 |	4 | Seagate | Constellation ES.3 
   (ST4000NM0033-9ZM) | 4TB   |

It isn't the end of the world if I lose the data, but some of the 
videos and photos are sentimental. There's no time crunch for me, 
so if it takes a long time to work through, I have the time to do 
so.

WKR,
Aaron

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 394 bytes --]