Boot fails: btrfs errno=-17 Object already exists

On my laptop running Fedora 37, after a system crash I can no longer boot into the system. Here is the dmsg output after trying to mount the partition from a live system:

[ 7197.629787] BTRFS info (device sda3): using crc32c (crc32c-intel) checksum algorithm
[ 7197.629796] BTRFS info (device sda3): disk space caching is enabled
[ 7197.835286] BTRFS info (device sda3): enabling ssd optimizations
[ 7197.835291] BTRFS info (device sda3): start tree-log replay
[ 7198.936162] ------------[ cut here ]------------
[ 7198.936165] BTRFS: Transaction aborted (error -17)
[ 7198.936174] WARNING: CPU: 0 PID: 11071 at fs/btrfs/delayed-inode.c:1182 __btrfs_run_delayed_items+0x16d/0x280
[ 7198.936180] Modules linked in: hid_logitech_hidpp hid_logitech_dj binfmt_misc uinput hid_apple hidp rfcomm snd_seq_dummy snd_hrtimer xt_CHECKSUM xt_MASQUERADE ip6table_mangle ip6table_nat iptable_mangle iptable_nat bridge stp llc ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt ipt_REJECT nf_reject_ipv4 xt_LOG qrtr nf_log_syslog xt_multiport xt_comment xt_limit xt_addrtype xt_conntrack ip6table_filter nf_conntrack_netbios_ns nf_conntrack_broadcast nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bnep snd_hda_codec_hdmi snd_soc_avs snd_soc_hda_codec snd_soc_skl snd_soc_hdac_hda snd_hda_ext_core snd_soc_sst_ipc intel_rapl_msr sunrpc snd_soc_sst_dsp snd_soc_acpi_intel_match intel_rapl_common snd_soc_acpi ath10k_pci snd_soc_core ath10k_core rtsx_usb_ms snd_ctl_led snd_compress ac97_bus intel_tcc_cooling snd_hda_codec_realtek mei_pxp memstick iTCO_wdt snd_hda_codec_generic x86_pkg_temp_thermal ledtrig_audio snd_pcm_dmaengine intel_pmc_bxt intel_powerclamp
[ 7198.936228]  mac80211 coretemp snd_hda_intel kvm_intel iTCO_vendor_support at24 mei_hdcp snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec btusb snd_hda_core btrtl snd_hwdep uvcvideo vfat btbcm snd_seq fat kvm videobuf2_vmalloc btintel snd_seq_device btmtk libarc4 irqbypass snd_pcm bluetooth videobuf2_memops ath rapl videobuf2_v4l2 intel_cstate videobuf2_common intel_uncore joydev cfg80211 squashfs snd_timer videodev acer_wmi loop mc sparse_keymap intel_wmi_thunderbolt snd i2c_i801 wmi_bmof pcspkr rfkill i2c_smbus soundcore mei_me mei idma64 intel_pch_thermal intel_xhci_usb_role_switch acpi_pad zram dm_crypt i915 drm_buddy rtsx_usb_sdmmc drm_display_helper mmc_core cec hid_multitouch crct10dif_pclmul uas crc32_pclmul crc32c_intel polyval_clmulni polyval_generic ghash_clmulni_intel r8169 serio_raw usb_storage ttm rtsx_usb i2c_hid_acpi i2c_hid video wmi scsi_dh_rdac scsi_dh_emc scsi_dh_alua ip6_tables ip_tables dm_multipath i2c_dev fuse
[ 7198.936285] CPU: 0 PID: 11071 Comm: mount Not tainted 6.0.12-300.fc37.x86_64 #1
[ 7198.936287] Hardware name: Acer Aspire V3-372/Aspire V3-372, BIOS V1.12 02/23/2017
[ 7198.936288] RIP: 0010:__btrfs_run_delayed_items+0x16d/0x280
[ 7198.936291] Code: 48 0f ba 2a 03 72 25 41 83 ff fb 0f 84 07 01 00 00 41 83 ff e2 0f 84 fd 00 00 00 44 89 fe 48 c7 c7 88 37 79 a4 e8 c2 a2 7b 00 <0f> 0b 44 89 f9 ba 9e 04 00 00 48 c7 c6 30 22 2c a4 4c 89 e7 e8 2b
[ 7198.936293] RSP: 0018:ffffb1478c85fa70 EFLAGS: 00010296
[ 7198.936295] RAX: 0000000000000026 RBX: ffff9fbd9749f6d8 RCX: 0000000000000000
[ 7198.936296] RDX: 0000000000000001 RSI: ffffffffa47aac1a RDI: 00000000ffffffff
[ 7198.936298] RBP: ffff9fbd9749f680 R08: 0000000000000000 R09: ffffb1478c85f910
[ 7198.936299] R10: 0000000000000003 R11: ffffffffa5146328 R12: ffff9fbb918d0888
[ 7198.936300] R13: ffff9fbb89b9da80 R14: ffff9fbb9fe67800 R15: 00000000ffffffef
[ 7198.936302] FS:  00007faedf105800(0000) GS:ffff9fbde2c00000(0000) knlGS:0000000000000000
[ 7198.936303] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7198.936304] CR2: 000055ac8540d008 CR3: 00000003174d4006 CR4: 00000000003706f0
[ 7198.936306] Call Trace:
[ 7198.936308]  <TASK>
[ 7198.936312]  btrfs_commit_transaction+0x319/0xc90
[ 7198.936318]  btrfs_recover_log_trees+0x3f2/0x650
[ 7198.936321]  ? replay_one_extent+0x7e0/0x7e0
[ 7198.936324]  open_ctree+0x12f4/0x1550
[ 7198.936329]  btrfs_mount_root.cold+0xe/0xa5
[ 7198.936335]  legacy_get_tree+0x24/0x50
[ 7198.936338]  vfs_get_tree+0x22/0xc0
[ 7198.936341]  vfs_kern_mount.part.0+0x73/0xb0
[ 7198.936343]  btrfs_mount+0x13a/0x3e0
[ 7198.936349]  ? legacy_get_tree+0x24/0x50
[ 7198.936350]  legacy_get_tree+0x24/0x50
[ 7198.936352]  vfs_get_tree+0x22/0xc0
[ 7198.936354]  path_mount+0x446/0xa60
[ 7198.936358]  __x64_sys_mount+0xf6/0x140
[ 7198.936361]  do_syscall_64+0x58/0x80
[ 7198.936365]  ? syscall_exit_to_user_mode+0x17/0x40
[ 7198.936368]  ? syscall_exit_to_user_mode+0x17/0x40
[ 7198.936369]  ? do_syscall_64+0x67/0x80
[ 7198.936372]  ? do_syscall_64+0x67/0x80
[ 7198.936375]  entry_SYSCALL_64_after_hwframe+0x63/0xcd
[ 7198.936378] RIP: 0033:0x7faedf2ecf6e
[ 7198.936399] Code: 48 8b 0d c5 5e 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 a5 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 92 5e 0c 00 f7 d8 64 89 01 48
[ 7198.936401] RSP: 002b:00007ffd733e9078 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
[ 7198.936403] RAX: ffffffffffffffda RBX: 00005564ffdb7550 RCX: 00007faedf2ecf6e
[ 7198.936404] RDX: 00005564ffdbe090 RSI: 00005564ffdbd900 RDI: 00005564ffdb7780
[ 7198.936405] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000007
[ 7198.936406] R10: 0000000000000000 R11: 0000000000000246 R12: 00005564ffdb7780
[ 7198.936407] R13: 00005564ffdbe090 R14: 00000000ffffffff R15: 00007faedf421076
[ 7198.936411]  </TASK>
[ 7198.936412] ---[ end trace 0000000000000000 ]---
[ 7198.936413] BTRFS: error (device sda3: state A) in __btrfs_run_delayed_items:1182: errno=-17 Object already exists
[ 7198.936418] BTRFS warning (device sda3: state EA): Skipping commit of aborted transaction.
[ 7198.936419] BTRFS: error (device sda3: state EA) in cleanup_transaction:1983: errno=-17 Object already exists
[ 7198.939182] BTRFS: error (device sda3: state EA) in btrfs_replay_log:2395: errno=-17 Object already exists (Failed to recover log tree)
[ 7198.960692] BTRFS error (device sda3: state EA): open_ctree failed

I ran sudo btrfs check --check-data-csum -p /dev/sda3, which found no errors:

Opening filesystem to check...
Checking filesystem on /dev/sda3
UUID: 5f3727cf-2c38-4bda-ad27-03b4bdbbbc18
[1/7] checking root items                      (0:00:07 elapsed, 3101951 items checked)
[2/7] checking extents                         (0:00:39 elapsed, 222836 items checked)
[3/7] checking free space cache                (0:00:07 elapsed, 437 items checked)
[4/7] checking fs roots                        (0:01:30 elapsed, 169866 items checked)
[5/7] checking csums against data              (0:20:15 elapsed, 1392091 items checked)
[6/7] checking root refs                       (0:00:00 elapsed, 26 items checked)
[7/7] checking quota groups skipped (not enabled on this FS)
found 421575835648 bytes used, no error found
total csum bytes: 406240592
total tree bytes: 3650437120
total fs tree bytes: 2793619456
total extent tree bytes: 315752448
btree space waste bytes: 734239898
file data blocks allocated: 7263968927744
 referenced 400996683776

Given the express warnings that you should not run btrfs-check --repair without expert consultation, I am here to get some advice on how to proceed.

Be careful with btrfs and remember that /dev/sda3 is never mounted. That is the root btrfs volume and it usually contains subvolumes ‘root’ and ‘home’ that are mounted as the actual file systems in use.

My entries in /etc/fstab for mounting the btrfs filesystems are

UUID=d50e8840-4c90-4145-9018-46cc09536df2 /                       btrfs   subvol=root,compress=zstd:1 0 0
UUID=d50e8840-4c90-4145-9018-46cc09536df2 /home                   btrfs   subvol=home,compress=zstd:1 0 0

For the / file system that can be translated on the command line to sudo mount -t btrfs -o subvol=root,compress=zstd:1 UUID=<your uuid here> /mnt
and the UUID for the btrfs file system can be found with lsblk -f

That lsblk command will also tell you the amount of used space within the file systems.

All this should be done within the live environment since it appears your main system does not boot.

Some (or all) of that may be due to using all the inodes even though the file system is not full of data. There are several posts here about lack of space (inodes) even though the btrfs file system is not full of data and most include the fixes.

Thank you for your quick response. The lsblk from my external SSD, sdb being the external drive:

steffen@acr-16-fdr ~ (main)> lsblk -f
NAME              FSTYPE      FSVER LABEL                 UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0             squashfs    4.0                                                                    0   100% /var/lib/snapd/snap/core18/2632
loop1             squashfs    4.0                                                                    0   100% /var/lib/snapd/snap/snapd/17883
loop2             squashfs    4.0                                                                    0   100% /var/lib/snapd/snap/core18/2566
loop3             squashfs    4.0                                                                    0   100% /var/lib/snapd/snap/snapd/17336
sda
├─sda1            vfat        FAT32                       DF4C-F6B6
├─sda2            ext4        1.0                         3a17f17a-0dcb-48e9-be7f-ce8d0845cffc
└─sda3            btrfs             fedora_localhost-live 5f3727cf-2c38-4bda-ad27-03b4bdbbbc18
sdb
├─sdb1            vfat        FAT32                       DBE7-0331                             555.2M     3% /boot/efi
├─sdb2            ext4        1.0                         2d5d50cc-dff2-4e16-9b2c-94d2644caa8d  733.2M    20% /boot
└─sdb3            crypto_LUKS 2                           1536043e-7e43-4e8a-9e0b-d0e4a0e0ea57
  └─luks-1536043e-7e43-4e8a-9e0b-d0e4a0e0ea57
                  btrfs             fedora_localhost-live 26a86f31-f1c6-4ad1-b006-9d8cb0c86678  132.1G    44% /home
                                                                                                              /
zram0                                                                                                         [SWAP]

I ran the proper mount command as instructed:

steffen@acr-16-fdr ~ (main)> sudo mount -t btrfs -o subvol=root,compress=zstd:1 UUID=5f3727cf-2c38-4bda-ad27-03b4bdbbbc18 /mnt
[sudo] password for steffen:
mount: /mnt: can't read superblock on /dev/sda3.
       dmesg(1) may have more information after failed mount system call.

dmesg shows this I/O error:

[14143.389971] sd 0:0:0:0: [sda] tag#14 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
[14143.389976] sd 0:0:0:0: [sda] tag#14 CDB: Read(10) 28 00 00 32 c8 80 00 00 08 00
[14143.389977] I/O error, dev sda, sector 3328128 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[14143.389980] Buffer I/O error on dev sda3, logical block 16, async page read

I googled this, but it did not seem to relate to the problem with inodes you described. Any further guidance would be much appreciated.

This is the correct btrfs UUID for fedora_localhost-live on /dev/sdb, or this one for the luks volume

/dev/sda3 does not show any subvolumes on

What happens if you do
sudo mount -t btrfs UUID=5f3727cf-2c38-4bda-ad27-03b4bdbbbc18 /mnt
Theoretically, if you had an installed system on /dev/sda there should be 2 subvolumes and this command should not work correctly.

Here is the output:

steffen@acr-16-fdr ~ (main)> sudo mount -t btrfs UUID=5f3727cf-2c38-4bda-ad27-03b4bdbbbc18 /mnt
[sudo] password for steffen:
mount: /mnt: can't read superblock on /dev/sda3.
       dmesg(1) may have more information after failed mount system call.

Also, I tried using smartctl on the drive and it failed, which makes me think this is a hardware issue:

steffen@acr-16-fdr ~ (main) [2]> sudo smartctl -a /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.0.12-300.fc37.x86_64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

Short INQUIRY response, skip product id
A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.
steffen@acr-16-fdr ~ (main) [2]> sudo smartctl -a -T permissive /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.0.12-300.fc37.x86_64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

Short INQUIRY response, skip product id

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK
Current Drive Temperature:     0 C
Drive Trip Temperature:        0 C

Read defect list: asked for grown list but didn't get it
Error Counter logging not supported

Device does not support Self Test logging

I would say that the smartctl output most likely shows a failed drive unless you are still able to mount /dev/sda1 and/or /dev/sda2

I am curious though about

Is that a local build of the kernel or of smartctl?
Did this problem show up at the same time as the update to the 6.0.12 kernel?

Cannot mount either of the other two:

steffen@acr-16-fdr ~ (main) [1]> sudo mount dev/sda2
mount: dev/sda2: can't find in /etc/fstab.
steffen@acr-16-fdr ~ (main) [1]> sudo mount dev/sda1
mount: dev/sda1: can't find in /etc/fstab.

What’s odd about that is that grub is still functional on that drive. So that means that one of these is successfully mounted upon boot, right?

Nothing custom here. Though I did not install smartctl directly through dnf. That was because when I entered the command and it wasn’t installed, I was prompted to install it. I always thought that was going through dnf in the background. Does that way use other repos?

According to Grub that install is still on 6.0.11, not sure how long after the last kernel upgrade the crash happened.

You omitted the leading / before “/dev”.

If grub is active on that drive it does not mean anything is mounted. Grub runs and /boot and /boot/efi are mounted only after the system mounts / which does not happen.

Using the proper paths in the mount command would tell you that.

Nothing is mounted on /dev/sda and this from your post above shows that grub booted and mounted from /dev/sdb at least for that boot.

It currently looks like the btrfs file system on /dev/sda3 may have been corrupted since it does not respond to any of the commands tried so far to access it.

My suggestion so far would be to reinstall on /dev/sda: Or to replace it.
That drive is at least partially functional as it shows in the lsblk output and it seems the btrfs file system may be the only part that is failed.

Just as a thought, how old is the drive on /dev/sda? Smartctl was unable to tell us anything about it.

Almost exactly three years.

Today I brought home another external SSD that is SATA M.2 like the problematic drive. I opened up the laptop, and at first just reseated the problematic drive, hoping it might just be a connectivity issue. Unfortunately, that changed nothing.

Then I put the drive from the external enclosure into the laptop. It works perfectly fine. So that excludes any hardware issues other than a drive defect.

I’m leaving the functional drive in the laptop for the moment and put the problematic drive into the external enclosure. Thus, now sda is the functional drive and sdb the problematic one:

[steffen@fdr-ext-1 ~]$ lsblk -f
NAME FSTYPE FSVER LABEL              UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
│    vfat   FAT32                    2A9C-12E0                             557.5M     3% /boot/efi
├─sda2
│    ext4   1.0                      89798fb3-9ea0-4198-8948-208facb5cb3b  550.5M    38% /boot
└─sda3
     crypto 2                        f516eaa9-f086-4607-bbaa-d7fed48390a0
  └─luks-f516eaa9-f086-4607-bbaa-d7fed48390a0
     btrfs        fedora_localhost-live
                                     6ed662fa-6af4-40f4-9892-afb08d37532d  184.7G    21% /home
                                                                                         /
sdb
├─sdb1
│    vfat   FAT32                    DF4C-F6B6
├─sdb2
│    ext4   1.0                      3a17f17a-0dcb-48e9-be7f-ce8d0845cffc    641M    27% /run/media/steffen/3a17f17a-0dcb-48e9-be7f-ce8d0845cffc
└─sdb3
     btrfs        fedora_localhost-live
                                     5f3727cf-2c38-4bda-ad27-03b4bdbbbc18
zram0
                                                                                         [SWAP]

Curiously, in this configuration smartctl actually does report something useful (so maybe a connectivity issue after all?):

[steffen@fdr-ext-1 ~]$ sudo smartctl -a /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.0.12-300.fc37.x86_64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family:     Crucial/Micron Client SSDs
Device Model:     CT500MX500SSD4
Serial Number:    1927E210D887
LU WWN Device Id: 5 00a075 1e210d887
Firmware Version: M3CR023
User Capacity:    500,107,862,016 bytes [500 GB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    Solid State Device
Form Factor:      M.2
TRIM Command:     Available
Device is:        In smartctl database 7.3/5319
ATA Version is:   ACS-3 T13/2161-D revision 5
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Mon Dec 19 19:07:33 2022 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82)	Offline data collection activity
					was completed without error.
					Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0)	The previous self-test routine completed
					without error or no self-test has ever
					been run.
Total time to complete Offline
data collection: 		(    0) seconds.
Offline data collection
capabilities: 			 (0x7b) SMART execute Offline immediate.
					Auto Offline data collection on/off support.
					Suspend Offline collection upon new
					command.
					Offline surface scan supported.
					Self-test supported.
					Conveyance Self-test supported.
					Selective Self-test supported.
SMART capabilities:            (0x0003)	Saves SMART data before entering
					power-saving mode.
					Supports SMART auto save timer.
Error logging capability:        (0x01)	Error logging supported.
					General Purpose Logging supported.
Short self-test routine
recommended polling time: 	 (   2) minutes.
Extended self-test routine
recommended polling time: 	 (  30) minutes.
Conveyance self-test routine
recommended polling time: 	 (   2) minutes.
SCT capabilities: 	       (0x0031)	SCT Status supported.
					SCT Feature Control supported.
					SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   100   100   000    Pre-fail  Always       -       0
  5 Reallocate_NAND_Blk_Cnt 0x0032   100   100   010    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       8813
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       4769
171 Program_Fail_Count      0x0032   100   100   000    Old_age   Always       -       0
172 Erase_Fail_Count        0x0032   100   100   000    Old_age   Always       -       0
173 Ave_Block-Erase_Count   0x0032   083   083   000    Old_age   Always       -       259
174 Unexpect_Power_Loss_Ct  0x0032   100   100   000    Old_age   Always       -       284
180 Unused_Reserve_NAND_Blk 0x0033   000   000   000    Pre-fail  Always       -       34
183 SATA_Interfac_Downshift 0x0032   100   100   000    Old_age   Always       -       1
184 Error_Correction_Count  0x0032   100   100   000    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   059   017   000    Old_age   Always       -       41 (Min/Max 0/83)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_ECC_Cnt 0x0032   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x0032   100   100   000    Old_age   Always       -       0
202 Percent_Lifetime_Remain 0x0030   083   083   001    Old_age   Offline      -       17
206 Write_Error_Rate        0x000e   100   100   000    Old_age   Always       -       0
210 Success_RAIN_Recov_Cnt  0x0032   100   100   000    Old_age   Always       -       0
246 Total_LBAs_Written      0x0032   100   100   000    Old_age   Always       -       48064514186
247 Host_Program_Page_Count 0x0032   100   100   000    Old_age   Always       -       805337373
248 FTL_Program_Page_Count  0x0032   100   100   000    Old_age   Always       -       2433229011

SMART Error Log Version: 1
Warning: ATA error count 0 inconsistent with error log pointer 4

ATA Error Count: 0
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error -3 occurred at disk power-on lifetime: 0 hours (0 days + 0 hours)
  When the command that caused the error occurred, the device was in an unknown state.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  00 ec 00 00 00 00 00

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  ec 00 00 00 00 00 00 00      00:00:00.000  IDENTIFY DEVICE
  ec 00 00 00 00 00 00 00      00:00:00.000  IDENTIFY DEVICE
  ec 00 00 00 00 00 00 00      00:00:00.000  IDENTIFY DEVICE
  ec 00 00 00 00 00 00 00      00:00:00.000  IDENTIFY DEVICE
  c8 00 00 00 00 00 00 00      00:00:00.000  READ DMA

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%      2840         -
# 2  Conveyance offline  Completed without error       00%      2069         -
# 3  Extended offline    Completed without error       00%      2061         -
# 4  Short offline       Completed without error       00%      2058         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

I could not make out any indication of a defect here.

Thanks, I was able to mount it now. (Had to make an edit here, because I also forgot to specify the mount point)

So you would advice against using btrfs check --repair to try and salvage the install?

The fact that you cannot mount either sdb1 or sdb2 indicates something wrong with the drive physically or that the partition table is damaged. We already knew something was wrong when you could not get a smartctl response and could not mount any of the partitions before you reconnected it.

The fact that smartctl is now able to provide more info seems to confirm that there may have been a connection issue, which could easily have led to corrupted data. Invalid write commands as a result of a failing and unstable connection could easily have damaged the partition table and more (and apparently did). An electronic failure on an SSD will also only continue to get worse. Please consider that as well.

It is up to you to decide how important recovery may be. Recover? or start as if a new drive?

I believe that there is one possible method to recover some data (photorec) and that would be time consuming and may not even give you intact files. Photorec might assist, but unless recovery is of paramount importance it seems easier to just totally wipe out the existing partition table then try creating a new partition table and start over as if the drive were brand new.

1 Like

Thank you for your patient advice. Important data is all backed up. The desire to restore the old install is just about all the hassle of setting up a fresh system and customizing it all to my liking. But your point about potential corruption ultimately outweighs that consideration. I think I will repair it just to satisfy my curiosity to what extent it is repairable at all and then set up a fresh install. Again, thank you very much for your help.

1 Like

Using the btrfs tools and attempting a repair seems a good way to learn about those tools and what they may be capable of. Even if recovery is not possible it is a learning opportunity without risking an operating system.

:nerd_face: