Well it happened once or twice before too, one time i had to take ownership of some folder that was responsible for some KDE functionality, it randomly lost permissions, and i did get new RAM, but it happened before new ram as well…
What should i do then?
I’d hate to randomly lose data - though, this seems unlikely, but still…
I see, Btrfs changed your whole system to read-only automatically when it detected some corrupted data. That is good as alarm to notice you immediately. It stops writing your data further, otherwise it will get more corruptions.
You have experienced this issue twice or more, it seems no coincidence, your hardware is probably the issue.
Now your data is ok after scrub, you need to backup first! Then check your hardware later.
I use Ext4 as a stable filesystem for my 2 main storage HDD’s, but I had BTRFS on my 10 year old Western Digital 2TB drive with movie archives.
BTRFS is great for my system SSD for a couple of reasons:
I run back-in-time rsync backups.
This means stability, if my SSD takes a bullet, I can buy a new one, reinstall and restore from back-in-time.
If I edit my passwd file and can’t log in, I can reboot and select a snapshot.
I switched after Timeshift had issues restoring rsync backups and I ended up reinstalling anyway - I don’t know if the parse list was just too long or what, but it kept failing with my exisiting snapshots… Thankfully, rsync snapshots are available on disk to be copied to a new installation.
I don’t have an exotic config, and encountered zero issues so far.
It can do, but it does not tell you which of the two is bad after test result.
Note: memtest has the limit and can not detect some errors of RAM when:
DMA transfer under certain circumstances.
Probability of bit error is low like random (One time test is not enough, you need repeat test more than 10 times.) It is related to:
Some external factor …
In my past, memtest did not help me to detect a random 1-bit error in my failing RAM, but Btrfs did.
How did I find my faulty RAM without using memtest:
I tested every single RAM and created any big file zip 20 GB, then copied it to other partition in the same disk more than 10 times repeats , then checked each file with checksum e.g SHA1 or SHA256 more than 10 times repeats, if all checksum results match correctly:
$ sha256sum 20GB_File
One of 4 RAMs showed up the error, rest others have no issue. That is why I caught the faulty RAM.
Well, memtest ran for 6 hours, 4 passes, 0 errors… I know i didn’t test each stick individually, but if any were showing errors, then i’d decouple them and find out which one it is. Both seem fine so i don’t think i have to do that.
Also, an obvious thing has been pointed to you early in the thread
At some point stop ignoring the first thing you should have tried:
INSTALL A MANJARO KERNEL NOW
When you’ll have done extensive tests with what comes with Manjaro, and find that you continue to see the exact same problematic behavior, you can then say it is not because of you external modified kernel that you see issues apparently only you have here on the forum.
Use logic it helps not wasting time. It may not be that, but why are you forcefully ignoring that obvious thing, I can’t tell…
You need to trim the big pieces first before detailing.
mprime-bin, left it on default options for half an hour, didn’t report any issues.
I’m not comfortable leaving stress tests on for longer so i stopped it.
I asked in this thread if it’s kernel related, people have told me no, so i didn’t.
But yeah, i guess i can try it.
No need to shout.
I’m definitely not the only one having issues with this, and this was on an official Manjaro kernel, though, granted, an older one. It was perfectly safe to assume the custom kernel wasn’t at fault here.
This exact thread actually solved one of the issues when this happened before. When some folder became not writeable due to permissions changing for no reason.
Because it’s not obvious it’s the kernel. I’m perfectly happy testing the normal one, but all evidence pointed to it not being the case, as others have stated here as well.
A different test idea is to copy your current storage to a different one with a different filesystem type, make it bootable and try running on that one for a month.
If no issues, then profit for you a one more brick in the wall for btrfs.
If issues continue, then continue debugging.
No issues so far. I once had that annoying KDE Unlock bug, but that’s not related. And that notification system for BTRFS that i installed didn’t show up once, and i copied about 22 GB of pictures from my mobile to the drive, no issues.
I did remove xanmod, so maybe it was that kernel related after all.
I do have another SSD where WIndows used to be, but i’m too lazy to sift through it to see what’s there, and if i just copy everything to a folder and name it “backup” (lol) it shall forever remain untouched.
But i don’t want to install the OS and configure it again, and chances are that, if i just run stock and browse internet on it, nothing will ever happen. A true test would be to do the exact same things i did on this install, then see if there’s a difference. But that’s too much time to re-do i’d like to avoid that if i can.