Open Buttars opened 4 months ago
It looks to me like /dev/sdb is on its way out. Have you done a SMART test?
It looks to me like /dev/sdb is on its way out. Have you done a SMART test?
/dev/sdb1 is a BTRFS partition that exists in a iSCSI hosted on my NAS. It is mounted to PROXMOX and mapped 1:1 with a single VM that hosts Portainer and a few dockerized services.
I've successfully recovered my data implying that it is the metadata that is corrupt not the data or drive. I've ran a quick SMART test which show's no issues. I'm running an extensive SMART test and will post the results below as soon as it completes.
Below are the two articles that lead me to be able to recover my data:
https://www.reddit.com/r/btrfs/comments/13heyas/rescuing_a_partition_with_parent_transid_verify/
https://bbs.archlinux.org/viewtopic.php?id=264191
Specifically this commands, btrfs-find-root /dev/sdb1
and btrfs restore -i -v -m -t (number) /dev/sdb1 ~/mount
where (number)
is the first block number in the list provided by the btrfs-find-root
command.
I then migrated the data to the new iSCSI drive by mounting the new partition and copy+pasting the contents of the restore directory to the new partition.
I suspect that this issue may be semi-reproducible if the BTRFS drive is mounted from the iSCSI (maybe optional?) and hard shutdown the windows box while accessing content from the BTRFS.
What is most odd is that I was able to view the contents of the BTRFS on Windows even after it was showing as corrupt on Linux. Is it possible that the driver is making incorrect assumptions about the superblock/root tree?
It looks to me like /dev/sdb is on its way out. Have you done a SMART test?
For context this is a relatively new drive with few on hours I purchased a few months back.
The extended SMART test shows HEALTHY.
I may have the same issue here with same symptoms. For a second, as winbtrfs is a LTS like stable driver I suspected openSUSE Tumbleweed which uses the latest stable kernel. However, it can be Windows 11 too. It also keeps getting updated. I did a "full smart test" via gsmartctl. It is OK.
update: btrfs even refuses to backup metadata. update2: I found a tool which is written in go and posted to the kernel mailing list. https://www.lukeshu.com/blog/btrfs-rec.html Unfortunately, it didn't work either.
update3 having no spares to provide 600 gb of free space for, I had to revert to ntfs for the moment so all structures were gone.
sudo bin/btrfs-rec inspect rebuild-mappings scan --pv /dev/sda1
10:50:50.2481 ERR : goroutine "/main" exited with error: device file "/dev/sda1": no superblocks
10:50:50.2482 INF thread=:shutdown_logger : shutting down (gracefully)...
10:50:50.2483 INF thread=:shutdown_status : final goroutine statuses:
10:50:50.2483 INF thread=:shutdown_status : /main: exited with error
btrfs-rec: error: device file "/dev/sda1": no superblocks
Lets leave the meta commentary for the other threads please. I'd like this thread to be solely about the issue or else it'll fall victim to the same fate as the other threads.
@IlgazC If your issue is the same then it is only the metadata that is corrupt and not the data itself. You can follow the steps mentioned above to check for valid data blocks and possibly recover the files. This does not change or modify your btrfs partition and requires another partition to store the data on. If the data recovery is successful this will confirm that your metadata was corrupted somehow which is what I was experiencing. I recommend starting there to confirm that the issue is the same.
Are you using an iSCSI or a vanilla btrfs partition on a physical drive?
Are you using an iSCSI or a vanilla btrfs partition on a physical drive?
A physical USB3 WD drive. Unfortunately, as the attempts to back up metadata also failed, and I don't have spare free space, I ended up restoring ntfs&files via duplicati. IMHO that "btrfs-rec" should be checked for possible disaster recovery function included in winbtrfs. Obviously as a terminal only command.
Turning off write caching in Windows seems to have fixed this issue for me. I'm not 100% sure yet, but it has survived at least 3 reboots so far. I'm keeping an eye on it.
I just tried 1.9 and updated some games (Blizzard, Steam, even Star Citizen!) on it. Booting Linux afterwards I had no errors in fs check :)
Similarly to #592 the btrfs partition is not able to be mounted to the Linux box after rebooting the Windows machine with the drive mounted. I was able to mount the drive into Windows same as #592.
I'm unable to use the driver since a Windows update broke the driver and bluescreens my PC when I try to load it. Any idea how I can recover my partitions?
dmesg