I was copying files from an NTFS hard drive to my current EOS installation which is using BTRFS + LUKS2, and a pop-up said it couldn’t copy certain files so I selected “skip all” and walked away. A little bit later I looked and the whole Plasma desktop had crashed/disappeared except for the dolphin window. When I switched to tty it was constantly spitting out BTRFS errors and I couldn’t figure out how to get it to stop so I could shut down the system properly, and eventually did a hard-shutdown with the power button . (I hadn’t enabled REISUB yet… live and learn.) My EOS install seems to be working perfectly fine after booting it back up.
I have a windows installation on another drive, and I think I must have not disabled fast startup, meaning the NTFS drive was still partially mounted or something. When I booted windows up it said something about checking drives for repair, which I quickly skipped. I’ve since disabled hibernation with the command on the arch wiki and shut down, so that should be off now, though I haven’t tried to copy files from that drive again.
My questions are:
Does it seem likely windows hibernation was causing this issue?
Are there any specific tests I could do or things to look for to confirm there’s no BTRFS or hardware issue?
Should I do a BTRFS scrub or something else?
I’d like to make sure I can trust my filesystem/hardware isn’t damaged/faulty before I continue using them normally.
Because the Btrfs filesystem and its original data are not corrupted → See your screenshot to show: You have 0 corrupt .
But Btrfs log just told you about many read/write issues while copying data from NTFS to Btrfs.
I am not sure if you do not have NTFS data on Btrfs after copying, as Btrfs would stop/reject the bad copying and threw error messages (But in my experience, Btrfs stopped copying corrupted data).
I don’t get it.
Do you mean that you want to hibernate Windows without shutting down, then go EOS and transfer data from NTFS to Btrfs, then go back to Windows?
Which Kernel version do you use?
I guess you’re using the “unstable” kernel 6.7 after installing EOS 2024 instead of LTS by default.
You should prepare a backup first, then test what you want. I am sure, no one here wants to test NTFS as Microsoft’s thing.
The number of reading errors was counted very high, more than 1 billion reading errors (including many reading repetition) when copying many many files from NTFS to Btrfs, that is what your screenshot showed.
My guess is what possible problem is caused:
Physical connection problems between two hard drives cause many reading errors (This is about hardware issue)
OR
The communication or translation between NTFS and Btrfs is not good, for example Btrfs reads bad NTFS file formats like “strange foreign language” and does not understand what it means, then it gives up the translation and throws out unreadable NTFS files in garbage.
. (I hadn’t enabled REISUB yet… live and learn.) My EOS install seems to be working perfectly fine after booting it back up.