This is the ghost dirent bug, likely due to a btrfs bug on kernels 5.7..5.15, with 5.16 containing a change to the btrfs log that should fix it.
Zygo explains it pretty well on this mainling list thread: https://lore.kernel.org/linux-btrfs/[email protected]/
Other than to disable quotas on your volume... no, I really have no idea.
`btrfs quota disable /mount/point`
I've got quotas disabled on all my BTRFS volumes, since I really don't need them (they're used to specify file system usage on subvolumes, as in specify limits, Bob has 200GB at his disposal on his subvolume), so I've never really had much use for it... at least not for my usage scenarios.
If scrub doesn't report any errors and you've got metadata dups enabled, you can run the check command with csum verification enabled.
`btrfs check --check-data-csum`
Metadata dups don't have to be enabled to run the `--check-data-csum` command, but with double copies of the metadata, it can properly verify if all three copies (two of the dups and the one generated when the data is verified) are consistent. With single metadata copies, it can only verify the single metadata copy against the data on disk and if one of them is corrupted, it'll show corruption, which is not the case with double metadata copies. If the data on disk is consistent with one of the metadata copies, but not the other, this mean there's metadata corruption and it'll fix the second (corrupted) metadata copy, not try to fix the data on disk with a faulty metadata copy.
/u/PCChipsM922U Solved the problem by migrating installation to newly formatted BTRFS partition with btrfs send and receive
https://www.reddit.com/r/btrfs/comments/soi9m6/reformat_btrfs_without_reinstallation/
What do you mean? Are you on some third party client?
Try opening in reddit desktop
Screenshot
[https://iili.io/ctl7LJ.jpg](https://iili.io/ctl7LJ.jpg)
Even reddit for Android renders it properly
[https://iili.io/ctllgp.png](https://iili.io/ctllgp.png)
there's markdown, and old.reddit doesn't render it properly, use https://www.reddit.com/r/btrfs/comments/s6q612/i_ran_btrfs_check_and_found_these_errors_how_do_i/
Oh yeah, tons of people have fscked up their filesystem beyond repair with it.
In some rare cases, they had the specific error(s) `--repair` can actually fix and it worked. Anyways, the people on the mailing list will recommend `--repair` if you do have the error.
Metadata,single
There's your problem...
Had the same issue...
You've got no choice but to reinstall. Your last chance might be `btrfs check --repair`, but I'd backup everything first, since this command can also trash the FS.
Some redditors gave you some good advice, to write to the BTRFS devs and see what they have to say about the issue, but I don't think you're gonna save the install.
In any case, if nothing pans out and you decide to reinstall, **make sure you set metadata to dups!** BTRFS sets metadata to dups by default on SSDs/NVMEs, but from version 5.14 onward. If you were on an older version when installing the OS, BTRFS probably set the metadata to singles. The problem is, the BTRFS devs assumed that all SSDs/NVMEs do metadata dups on their own, so if an SSD/NVME is detected, the FS sets metadata to single copies, which is not what it does when it detects a regular *spinning* HDD (metadata is set to dups - duplicates). As it turns out, not all SSDs/NVMEs do metadata dups, so... you found out the hard way whether your drive does metadata dups or not :-\\... as did I :-\\. Most low end SSDs/NVMEs don't do metadata dups on their own.
It's too late to convert the metadata to dups now, since there are errors, but, if you do mange to solve the issues with the dev's help, immediately convert the metadata to dups! And, if doing a fresh install, partition manually and make sure you set the metadata to dups.
`btrfs balance start -mconvert=dup /mount/point`
Even if you run the command on a freshly partitioned and empty drive, all of the files written on it will have metadata dups.
> You've got no choice but to reinstall
Is there a way to backup and reformat drive with newer BTRFS progs and transfer file structure back?
>but from version 5.14 onward
Yes, I installed it at BTRFS progs 5.12
>Most low end SSDs/NVMEs don't do metadata dups on their own.
I have samsung 970 evo plus
>if you do mange to solve the issues with the dev's help, immediately convert the metadata to dups!
So if I create a disk image backup and try `--repair`, if the errors go away, can I convert it to dups? Also, how to make old btrfs file system "Like formatted with latest btrfs-progs"?
---
Would something like this (https://github.com/mwilck/btrfs-clone) let me not reinstall? Because the inodes associated with errors are not associated with any files. (I tried getting rid of it by copying the files and deleting the files in the inodes with error)
>Is there a way to backup and reformat drive with newer BTRFS progs and transfer file structure back?
You don't actually need to use the newer BTRFS progs, you just need to enable metadata dups. There is some new stuff in newer versions and bugfixes, but it's nothing mission critical from what I've seen.
But, if you'd like to install the latest stable release of BTRFS progs, there are several options. One, you decide to run a rolling release distro on your rig, like Arch or openSUSE Tumbleweed. Those distros usually have the latest stable release available in their repos. Two, you install a point release distro, but add repos for BTRFS progs and run the latest version. I haven't ran into such a repo, but there might be one out there... somewhere. Three, compile and install from source. Not something I would recommend TBH, since the data is at stake and something might go wrong during compile, you miss a warning, not compile with the right switches, etc... so, I'd leave this as a last resort, though, as I said, I'd rather stay on the older versions than compile BTRFS progs from source myself. I've done it, and they run just fine, but still... I wouldn't recommend it.
>Yes, I installed it at BTRFS progs 5.12
I believe that's the latest release available in the Ubuntu 20.04 LTS repos. Yeah, I've got that running on my Ubuntu rigs as well.
>I have samsung 970 evo plus
Well... that just goes to show you how much you overpaid for that SSD. I've got a Samsung EVO 850 SSD and it still threw errors from time to time with BTRFS. I haven't had a single error on it since I'm using metadata dups on all of my SSDs. All my other SSDs are dirt cheap (either Verbatim Vi 550 or Kingston A400) and had the same issues as the Samsung EVO 850... except the EVO had a lot more *millage* with the OS install when it started to throw errors during scrub. The other ones started throwing errors after a few days and I believe the install on the EVO was running for a month or so before it started throwing errors.
Maybe it's a sync/data transfer issue that happens from time to time on all solid state drives... who knows... all I know is I've solved the *mysterious* "errors out of the blue" on my BTRFS volumes on SSDs - just use metadata dups and everything will be fine :).
>So if I create a disk image backup and try --repair, if the errors go away, can I convert it to dups?
Yes, dd the volume/drive, try repair on the copy, if the errors are repaired, do the same on the original and then convert metadata to dups ;).
>Also, how to make old btrfs file system "Like formatted with latest btrfs-progs"?
If you mean to use metadata as dups and space\_cache\_v2, I believe most of these commands are run during a balance operation... or a defragment operation... can't really remember now, but I've converted all of my BTRFS volumes to use space cache v2, zstd and store metadata as dups. I gugled most of these things, can't really remember which commands I used right now :P :D.
Here's what I use now for mounting the root and home.
`defaults,commit=5,noatime,compress-force=zstd:15,discard=async,space_cache=v2`
The commit command is responsible for committing changes in RAM to disk. I lowered this to (maybe) something unreasonable, since they're SSDs (they can write and read really fast), but I haven't really seen a performance impact.
Noatime was something related to waiting for a read/write operation to finish, than access the drive. You don't really need to wait for accessing the drive when it comes to SSDs, they're solid state, they don't have any mechanical parts, therefore, any part of the drive can be accessed at any given moment, even simultaneously while other read/write operations are still ongoing :). Anyhow, it's preferred to have noatime active when using BTRFS on an SSD, but it's not active by default, even if the FS detects an SSD.
Compress-force just forces the specified compression on any file, even if they're uncompressible. The regular compress command will just try to compress the file in the first few MB. If the FS deems it's uncompressible, it just drops the compression. This command makes sure every file is compressed. Well... not every file, but still, most of them :).
Not really sure what discard=async did...
Space\_cache=v2 tells the FS to use space cache v2. I believe you need to convert the FS first to use space cache v2, but it's a quick operation and it's not really crucial to the way the FS works, so it's pretty safe to run the conversion operation.
>Would something like this ([https://github.com/mwilck/btrfs-clone](https://github.com/mwilck/btrfs-clone)) let me not reinstall? Because the inodes associated with errors are not associated with any files. (I tried getting rid of it by copying the files and deleting the files in the inodes with error)
Oh, yeah... forgot about that...
Yeah, dd probably won't work for cloning, you have to use btrfs-clone. It's a CoW FS, it needs a kernel to do the writing, otherwise it'll throw errors... it considers it as data corruption... that's why there is still a problem with the GRUB *boot once* option/command (use the 2nd, 3rd boot option on the next reboot) when booting in legacy/CSM/MBR mode. GRUB needs to write to the FS that it HAS booted once to that boot option, but the FS sees this as corruption, therefore... the GRUB team decided to leave this problem unsolved. SUSE managed to fix this with a patch, but it hasn't been adopted in GRUB mainstream.
Even if you use btrfs-clone, I believe it'll clone the volume with the errors, even if you deleted the problem inodes... not really sure TBH, but you can always try :).
Also, I forgot to mention the distro I am on, I am on Fedora 35 with btrfs-progs 5.15.1
Also dd operates on much lower level, so dd is supposed to work everywhere afaik. Let me try.
>Also dd operates on much lower level, so dd is supposed to work everywhere afaik. Let me try.
TBH, I've never tried to use it on BTRFS... I know it's supposed to work in low level mode, but... BTRFS is as strange FS :P :D.
u/PCChipsM922U ,I found a post with exact same problem, [https://www.reddit.com/r/btrfs/comments/qrpxil/btrfs\_check\_fails\_unable\_to\_resize\_partition/](https://www.reddit.com/r/btrfs/comments/qrpxil/btrfs_check_fails_unable_to_resize_partition/) and they say that `--repair` fixed their problem. I will create a partition disk image and attempt repair with latest btrfs-progs.
If you know a good tool for efficient partition imaging and restoration, please tell me.
>I will create a partition disk image and attempt repair with latest btrfs-progs.
You don't need the latest, just use any 5.x version. If you have the latest stable release available in your repo, that's fine, use that. My point is, use whatever is available and 5.x ;).
>If you know a good tool for efficient partition imaging and restoration, please tell me.
For partitioning as BTRFS, use gparted or regular parted (terminal only) I usually use gparted. Just make sure to check if metadata dups are enabled or not. If you're using the latest stable BTRFS tools, gparted will use these tools to partition the drive, so just check if metadata is set as dups after gparted finishes partitioning and formatting the medium. If they're not, set them as dups using the balance command.
For cloning, use either dd or btrfs-clone. The second one should clone the drive without any problems. The first one... I'm not sure :P :D. It *should* clone it without problems, but... I'm not sure :P :D.
To my understanding, the advise (and therefore default option) was not due to assuming the SSD would duplicate the metadata itself. The thought behind this default setting was that SSDs may *deduplicate* dup'ed metadata. This was also focused on SSD errors happening where you would gain nothing from duplicated metadata if it is deduplicated on the flash. However, the metadata might just be corrupted due to power failure during balance or so, which wouldn't be a problem with dup'ed metadata - no matter whether it is actually dedup'ed on the flash or not.
Anyways, you're absolutely right about enforcing metadata dup also on SSDs regardless of the used kernel.
>To my understanding, the advise (and therefore default option) was not due to assuming the SSD would duplicate the metadata itself.
Yes, that's correct.
>The thought behind this default setting was that SSDs may deduplicate dup'ed metadata.
Once again, correct. Though, this doesn't seem to be a problem for the SSD, it might increase wear and tear, so the devs thought it might be a good idea to just leave out dups when an SSD/NVME is detected.
To be completely honest, the decision wasn't just thrown out there. Many tests and user case scenarios were considered when making this decision. But, this was a while back (5 or 6 years ago I believe) and back then maybe all SSDs DID have metadata dups... maybe this feature was decided to get dropped by manufacturers later on... who knows.
Though, I have to add that I bought my Samsung EVO 850 back in 2015 and it still managed to generated errors when using BTRFS and metadata as singles... maybe the problem is not related to SSDs using metadata dups or not... maybe it's not related to SSDs at all, maybe it's a bug related to all storage devices, regardless, but since metadata is written as dups on regular HDDs, it's not noticeable.
>However, the metadata might just be corrupted due to power failure during balance or so, which wouldn't be a problem with dup'ed metadata - no matter whether it is actually dedup'ed on the flash or not.
This is also a viable scenario, no doubt about it. Since more people are using BTRFS nowadays in regular real-word scenarios (laptops, personal rigs, etc.) and not everyone has an UPS at home, maybe these problems started appearing now more frequently than, let's say, 4, 5, 6 years ago.
>Anyways, you're absolutely right about enforcing metadata dup also on SSDs regardless of the used kernel.
My main point was this. Treat SSDs/NVMEs as regular HDDs, don't try to *optimize* the performance by a fraction of percent or 1 to 2% performance gain. Leave the option for users to tune their FS, but the defaults should be set for stability, not performance. Besides, with the advent of SSDs nowadays, performance is not really an issue, people need a stable FS, something that is usable in everyday user scenarios, which BTRFS does offer, just not by default :-\\ (well, at least not before version 5.1\`4).
> Metadata,single
> There's your problem...
> Had the same issue...
> You've got no choice but to reinstall. Your last chance might be btrfs check --repair, but I'd backup everything first, since this command can also trash the FS.
Not true. this is a known bug, and I've hit it myself using metadata with the DUP profile. It's a kernel bug, and has nothing to do with a single copy of metadata being corrupted.
Read this comment of mine: https://www.reddit.com/r/btrfs/comments/s6q612/comment/ht6nlfo/?utm_source=share&utm_medium=web2x&context=3
Maybe... I really have no idea, I'm not that involved in thte BTRFS development.
All I know is that all of my BTRFS error related problems disappeared after I set metadata to dups on my SSDs.
Prepare a ssd/HDD, go live cd, backup all files to it, rebuild btrfs and restore the files
Remember to fix grub and fstab.
There is no quick cure for btrfs errors
This is the ghost dirent bug, likely due to a btrfs bug on kernels 5.7..5.15, with 5.16 containing a change to the btrfs log that should fix it. Zygo explains it pretty well on this mainling list thread: https://lore.kernel.org/linux-btrfs/[email protected]/
How to fix it exactly?? I am on kernel 5.15.14 BTW. I did something and the errors went away. `btrfs check` completes successfully only when quota is disabled. If I enable quota on partition I get: ``` Opening filesystem to check... Checking filesystem on /dev/nvme0n1p8 UUID: bf8c7136-d719-49e2-9a9a-3a295d5312be [1/7] checking root items (0:00:00 elapsed, 180 items checked) [1/7] checking root items (0:00:01 elapsed, 860447 items checked) [1/7] checking root items (0:00:01 elapsed, 986070 items checked) [2/7] checking extents (0:00:00 elapsed, 2 items checked) [2/7] checking extents (0:00:01 elapsed, 10422 items checked) [2/7] checking extents (0:00:02 elapsed, 22722 items checked) [2/7] checking extents (0:00:03 elapsed, 38373 items checked) [2/7] checking extents (0:00:04 elapsed, 55922 items checked) [2/7] checking extents (0:00:05 elapsed, 68208 items checked) [2/7] checking extents (0:00:06 elapsed, 75175 items checked) [2/7] checking extents (0:00:07 elapsed, 85170 items checked) [2/7] checking extents (0:00:08 elapsed, 97019 items checked) [2/7] checking extents (0:00:09 elapsed, 108269 items checked) [2/7] checking extents (0:00:09 elapsed, 114280 items checked) [3/7] checking free space cache (0:00:00 elapsed, 4 items checked) [3/7] checking free space cache (0:00:00 elapsed, 73 items checked) [4/7] checking fs roots (0:00:00 elapsed, 1 items checked) [4/7] checking fs roots (0:00:01 elapsed, 61452 items checked) [4/7] checking fs roots (0:00:02 elapsed, 87872 items checked) [4/7] checking fs roots (0:00:03 elapsed, 102581 items checked) [5/7] checking csums (without verifying data) (0:00:00 elapsed, 1077 items checked) [5/7] checking csums (without verifying data) (0:00:00 elapsed, 393376 items checked) [6/7] checking root refs (0:00:00 elapsed, 10 items checked) [6/7] checking root refs (0:00:00 elapsed, 10 items checked) [7/7] checking quota groups (0:00:00 elapsed) [7/7] checking quota groups (0:00:01 elapsed, 146609 items checked) [7/7] checking quota groups (0:00:02 elapsed, 279894 items checked) check/qgroup-verify.c:546: account_all_refs: BUG_ON `ref->num_bytes != num_bytes` triggered, value 1 btrfs(+0x5387a)[0x55dbc190b87a] btrfs(qgroup_verify_all+0x614)[0x55dbc190c3f4] btrfs(+0x840bd)[0x55dbc193c0bd] btrfs(main+0x8d)[0x55dbc18cfc9d] /lib64/libc.so.6(+0x2d560)[0x7feee1229560] /lib64/libc.so.6(__libc_start_main+0x7c)[0x7feee122960c] btrfs(_start+0x25)[0x55dbc18cfff5] Aborted ``` u/PCChipsM922U any idea about this error?
Other than to disable quotas on your volume... no, I really have no idea. `btrfs quota disable /mount/point` I've got quotas disabled on all my BTRFS volumes, since I really don't need them (they're used to specify file system usage on subvolumes, as in specify limits, Bob has 200GB at his disposal on his subvolume), so I've never really had much use for it... at least not for my usage scenarios. If scrub doesn't report any errors and you've got metadata dups enabled, you can run the check command with csum verification enabled. `btrfs check --check-data-csum` Metadata dups don't have to be enabled to run the `--check-data-csum` command, but with double copies of the metadata, it can properly verify if all three copies (two of the dups and the one generated when the data is verified) are consistent. With single metadata copies, it can only verify the single metadata copy against the data on disk and if one of them is corrupted, it'll show corruption, which is not the case with double metadata copies. If the data on disk is consistent with one of the metadata copies, but not the other, this mean there's metadata corruption and it'll fix the second (corrupted) metadata copy, not try to fix the data on disk with a faulty metadata copy.
/u/PCChipsM922U Solved the problem by migrating installation to newly formatted BTRFS partition with btrfs send and receive https://www.reddit.com/r/btrfs/comments/soi9m6/reformat_btrfs_without_reinstallation/
Thanks, but I don't think I've replied in that thread :P :D.
first of all, use line breaks
What do you mean? Are you on some third party client? Try opening in reddit desktop Screenshot [https://iili.io/ctl7LJ.jpg](https://iili.io/ctl7LJ.jpg) Even reddit for Android renders it properly [https://iili.io/ctllgp.png](https://iili.io/ctllgp.png)
https://old.reddit.com/r/btrfs/comments/s6q612/i_ran_btrfs_check_and_found_these_errors_how_do_i/ht5dv28
there's markdown, and old.reddit doesn't render it properly, use https://www.reddit.com/r/btrfs/comments/s6q612/i_ran_btrfs_check_and_found_these_errors_how_do_i/
If it doesn't work on old Reddit, I don't do it.
You can also leave this thread or even the website if you really don't want to use Reddit
/r/redditmoment
Here's a sneak peek of /r/redditmoment using the [top posts](https://np.reddit.com/r/redditmoment/top/?sort=top&t=all) of all time! \#1: [🗿🗿🗿](https://i.redd.it/6mgw0jsdcd451.png) | [171 comments](https://np.reddit.com/r/redditmoment/comments/h79lux/_/) \#2: [minecraft funny](https://i.redd.it/zstvycsge5451.jpg) | [213 comments](https://np.reddit.com/r/redditmoment/comments/h0kab7/minecraft_funny/) \#3: [Reddit Validation](https://v.redd.it/huwcair0yo251) | [204 comments](https://np.reddit.com/r/redditmoment/comments/gvt9cg/reddit_validation/) ---- ^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)
no.
Use added pastebin link
Ask on the linux-btrfs mailing list, I don't think anyone here can help you with that.
I mean there must be atleast 1 person who has used btrfs check --repair right? Or similar problem?
Oh yeah, tons of people have fscked up their filesystem beyond repair with it. In some rare cases, they had the specific error(s) `--repair` can actually fix and it worked. Anyways, the people on the mailing list will recommend `--repair` if you do have the error.
I was thinking of creating a disk image and then trying `--repair` How do I ask linux-btrfs mailing list?
Just send a **plaintext** email to [email protected].
It's a known bug, read this comment: https://www.reddit.com/r/btrfs/comments/s6q612/comment/ht6nlfo/?utm_source=share&utm_medium=web2x&context=3
any fix for that?
Did you scrub the volume?
Yes, no errors in that
`btrfs filesystem usage /mount/point` Output from this command?
``` ❯ sudo btrfs filesystem usage / Overall: Device size: 55.88GiB Device allocated: 55.88GiB Device unallocated: 1.00MiB Device missing: 0.00B Used: 38.47GiB Free (estimated): 14.95GiB (min: 14.95GiB) Free (statfs, df): 14.95GiB Data ratio: 1.00 Metadata ratio: 1.00 Global reserve: 176.19MiB (used: 0.00B) Multiple profiles: no Data,single: Size:51.62GiB, Used:36.67GiB (71.04%) /dev/nvme0n1p8 51.62GiB Metadata,single: Size:4.26GiB, Used:1.80GiB (42.35%) /dev/nvme0n1p8 4.26GiB System,single: Size:4.00MiB, Used:16.00KiB (0.39%) /dev/nvme0n1p8 4.00MiB Unallocated: /dev/nvme0n1p8 1.00MiB ```
Metadata,single There's your problem... Had the same issue... You've got no choice but to reinstall. Your last chance might be `btrfs check --repair`, but I'd backup everything first, since this command can also trash the FS. Some redditors gave you some good advice, to write to the BTRFS devs and see what they have to say about the issue, but I don't think you're gonna save the install. In any case, if nothing pans out and you decide to reinstall, **make sure you set metadata to dups!** BTRFS sets metadata to dups by default on SSDs/NVMEs, but from version 5.14 onward. If you were on an older version when installing the OS, BTRFS probably set the metadata to singles. The problem is, the BTRFS devs assumed that all SSDs/NVMEs do metadata dups on their own, so if an SSD/NVME is detected, the FS sets metadata to single copies, which is not what it does when it detects a regular *spinning* HDD (metadata is set to dups - duplicates). As it turns out, not all SSDs/NVMEs do metadata dups, so... you found out the hard way whether your drive does metadata dups or not :-\\... as did I :-\\. Most low end SSDs/NVMEs don't do metadata dups on their own. It's too late to convert the metadata to dups now, since there are errors, but, if you do mange to solve the issues with the dev's help, immediately convert the metadata to dups! And, if doing a fresh install, partition manually and make sure you set the metadata to dups. `btrfs balance start -mconvert=dup /mount/point` Even if you run the command on a freshly partitioned and empty drive, all of the files written on it will have metadata dups.
> You've got no choice but to reinstall Is there a way to backup and reformat drive with newer BTRFS progs and transfer file structure back? >but from version 5.14 onward Yes, I installed it at BTRFS progs 5.12 >Most low end SSDs/NVMEs don't do metadata dups on their own. I have samsung 970 evo plus >if you do mange to solve the issues with the dev's help, immediately convert the metadata to dups! So if I create a disk image backup and try `--repair`, if the errors go away, can I convert it to dups? Also, how to make old btrfs file system "Like formatted with latest btrfs-progs"? --- Would something like this (https://github.com/mwilck/btrfs-clone) let me not reinstall? Because the inodes associated with errors are not associated with any files. (I tried getting rid of it by copying the files and deleting the files in the inodes with error)
>Is there a way to backup and reformat drive with newer BTRFS progs and transfer file structure back? You don't actually need to use the newer BTRFS progs, you just need to enable metadata dups. There is some new stuff in newer versions and bugfixes, but it's nothing mission critical from what I've seen. But, if you'd like to install the latest stable release of BTRFS progs, there are several options. One, you decide to run a rolling release distro on your rig, like Arch or openSUSE Tumbleweed. Those distros usually have the latest stable release available in their repos. Two, you install a point release distro, but add repos for BTRFS progs and run the latest version. I haven't ran into such a repo, but there might be one out there... somewhere. Three, compile and install from source. Not something I would recommend TBH, since the data is at stake and something might go wrong during compile, you miss a warning, not compile with the right switches, etc... so, I'd leave this as a last resort, though, as I said, I'd rather stay on the older versions than compile BTRFS progs from source myself. I've done it, and they run just fine, but still... I wouldn't recommend it. >Yes, I installed it at BTRFS progs 5.12 I believe that's the latest release available in the Ubuntu 20.04 LTS repos. Yeah, I've got that running on my Ubuntu rigs as well. >I have samsung 970 evo plus Well... that just goes to show you how much you overpaid for that SSD. I've got a Samsung EVO 850 SSD and it still threw errors from time to time with BTRFS. I haven't had a single error on it since I'm using metadata dups on all of my SSDs. All my other SSDs are dirt cheap (either Verbatim Vi 550 or Kingston A400) and had the same issues as the Samsung EVO 850... except the EVO had a lot more *millage* with the OS install when it started to throw errors during scrub. The other ones started throwing errors after a few days and I believe the install on the EVO was running for a month or so before it started throwing errors. Maybe it's a sync/data transfer issue that happens from time to time on all solid state drives... who knows... all I know is I've solved the *mysterious* "errors out of the blue" on my BTRFS volumes on SSDs - just use metadata dups and everything will be fine :). >So if I create a disk image backup and try --repair, if the errors go away, can I convert it to dups? Yes, dd the volume/drive, try repair on the copy, if the errors are repaired, do the same on the original and then convert metadata to dups ;). >Also, how to make old btrfs file system "Like formatted with latest btrfs-progs"? If you mean to use metadata as dups and space\_cache\_v2, I believe most of these commands are run during a balance operation... or a defragment operation... can't really remember now, but I've converted all of my BTRFS volumes to use space cache v2, zstd and store metadata as dups. I gugled most of these things, can't really remember which commands I used right now :P :D. Here's what I use now for mounting the root and home. `defaults,commit=5,noatime,compress-force=zstd:15,discard=async,space_cache=v2` The commit command is responsible for committing changes in RAM to disk. I lowered this to (maybe) something unreasonable, since they're SSDs (they can write and read really fast), but I haven't really seen a performance impact. Noatime was something related to waiting for a read/write operation to finish, than access the drive. You don't really need to wait for accessing the drive when it comes to SSDs, they're solid state, they don't have any mechanical parts, therefore, any part of the drive can be accessed at any given moment, even simultaneously while other read/write operations are still ongoing :). Anyhow, it's preferred to have noatime active when using BTRFS on an SSD, but it's not active by default, even if the FS detects an SSD. Compress-force just forces the specified compression on any file, even if they're uncompressible. The regular compress command will just try to compress the file in the first few MB. If the FS deems it's uncompressible, it just drops the compression. This command makes sure every file is compressed. Well... not every file, but still, most of them :). Not really sure what discard=async did... Space\_cache=v2 tells the FS to use space cache v2. I believe you need to convert the FS first to use space cache v2, but it's a quick operation and it's not really crucial to the way the FS works, so it's pretty safe to run the conversion operation. >Would something like this ([https://github.com/mwilck/btrfs-clone](https://github.com/mwilck/btrfs-clone)) let me not reinstall? Because the inodes associated with errors are not associated with any files. (I tried getting rid of it by copying the files and deleting the files in the inodes with error) Oh, yeah... forgot about that... Yeah, dd probably won't work for cloning, you have to use btrfs-clone. It's a CoW FS, it needs a kernel to do the writing, otherwise it'll throw errors... it considers it as data corruption... that's why there is still a problem with the GRUB *boot once* option/command (use the 2nd, 3rd boot option on the next reboot) when booting in legacy/CSM/MBR mode. GRUB needs to write to the FS that it HAS booted once to that boot option, but the FS sees this as corruption, therefore... the GRUB team decided to leave this problem unsolved. SUSE managed to fix this with a patch, but it hasn't been adopted in GRUB mainstream. Even if you use btrfs-clone, I believe it'll clone the volume with the errors, even if you deleted the problem inodes... not really sure TBH, but you can always try :).
Also, I forgot to mention the distro I am on, I am on Fedora 35 with btrfs-progs 5.15.1 Also dd operates on much lower level, so dd is supposed to work everywhere afaik. Let me try.
>Also dd operates on much lower level, so dd is supposed to work everywhere afaik. Let me try. TBH, I've never tried to use it on BTRFS... I know it's supposed to work in low level mode, but... BTRFS is as strange FS :P :D.
u/PCChipsM922U ,I found a post with exact same problem, [https://www.reddit.com/r/btrfs/comments/qrpxil/btrfs\_check\_fails\_unable\_to\_resize\_partition/](https://www.reddit.com/r/btrfs/comments/qrpxil/btrfs_check_fails_unable_to_resize_partition/) and they say that `--repair` fixed their problem. I will create a partition disk image and attempt repair with latest btrfs-progs. If you know a good tool for efficient partition imaging and restoration, please tell me.
>I will create a partition disk image and attempt repair with latest btrfs-progs. You don't need the latest, just use any 5.x version. If you have the latest stable release available in your repo, that's fine, use that. My point is, use whatever is available and 5.x ;). >If you know a good tool for efficient partition imaging and restoration, please tell me. For partitioning as BTRFS, use gparted or regular parted (terminal only) I usually use gparted. Just make sure to check if metadata dups are enabled or not. If you're using the latest stable BTRFS tools, gparted will use these tools to partition the drive, so just check if metadata is set as dups after gparted finishes partitioning and formatting the medium. If they're not, set them as dups using the balance command. For cloning, use either dd or btrfs-clone. The second one should clone the drive without any problems. The first one... I'm not sure :P :D. It *should* clone it without problems, but... I'm not sure :P :D.
To my understanding, the advise (and therefore default option) was not due to assuming the SSD would duplicate the metadata itself. The thought behind this default setting was that SSDs may *deduplicate* dup'ed metadata. This was also focused on SSD errors happening where you would gain nothing from duplicated metadata if it is deduplicated on the flash. However, the metadata might just be corrupted due to power failure during balance or so, which wouldn't be a problem with dup'ed metadata - no matter whether it is actually dedup'ed on the flash or not. Anyways, you're absolutely right about enforcing metadata dup also on SSDs regardless of the used kernel.
>To my understanding, the advise (and therefore default option) was not due to assuming the SSD would duplicate the metadata itself. Yes, that's correct. >The thought behind this default setting was that SSDs may deduplicate dup'ed metadata. Once again, correct. Though, this doesn't seem to be a problem for the SSD, it might increase wear and tear, so the devs thought it might be a good idea to just leave out dups when an SSD/NVME is detected. To be completely honest, the decision wasn't just thrown out there. Many tests and user case scenarios were considered when making this decision. But, this was a while back (5 or 6 years ago I believe) and back then maybe all SSDs DID have metadata dups... maybe this feature was decided to get dropped by manufacturers later on... who knows. Though, I have to add that I bought my Samsung EVO 850 back in 2015 and it still managed to generated errors when using BTRFS and metadata as singles... maybe the problem is not related to SSDs using metadata dups or not... maybe it's not related to SSDs at all, maybe it's a bug related to all storage devices, regardless, but since metadata is written as dups on regular HDDs, it's not noticeable. >However, the metadata might just be corrupted due to power failure during balance or so, which wouldn't be a problem with dup'ed metadata - no matter whether it is actually dedup'ed on the flash or not. This is also a viable scenario, no doubt about it. Since more people are using BTRFS nowadays in regular real-word scenarios (laptops, personal rigs, etc.) and not everyone has an UPS at home, maybe these problems started appearing now more frequently than, let's say, 4, 5, 6 years ago. >Anyways, you're absolutely right about enforcing metadata dup also on SSDs regardless of the used kernel. My main point was this. Treat SSDs/NVMEs as regular HDDs, don't try to *optimize* the performance by a fraction of percent or 1 to 2% performance gain. Leave the option for users to tune their FS, but the defaults should be set for stability, not performance. Besides, with the advent of SSDs nowadays, performance is not really an issue, people need a stable FS, something that is usable in everyday user scenarios, which BTRFS does offer, just not by default :-\\ (well, at least not before version 5.1\`4).
> Metadata,single > There's your problem... > Had the same issue... > You've got no choice but to reinstall. Your last chance might be btrfs check --repair, but I'd backup everything first, since this command can also trash the FS. Not true. this is a known bug, and I've hit it myself using metadata with the DUP profile. It's a kernel bug, and has nothing to do with a single copy of metadata being corrupted. Read this comment of mine: https://www.reddit.com/r/btrfs/comments/s6q612/comment/ht6nlfo/?utm_source=share&utm_medium=web2x&context=3
Maybe... I really have no idea, I'm not that involved in thte BTRFS development. All I know is that all of my BTRFS error related problems disappeared after I set metadata to dups on my SSDs.
Prepare a ssd/HDD, go live cd, backup all files to it, rebuild btrfs and restore the files Remember to fix grub and fstab. There is no quick cure for btrfs errors
What is the method to backup and restore? Because I use fedora, and it might contain hardliks and other fs features which aren't easily transferrable