From ArchWiki
Jump to navigation Jump to search
Note: The name of the file system does not seem to have an official capitalization, so the rule for the ArchWiki has been arbitrarily set to use "Btrfs" (capital "B" and the rest lower-case); "btrfs" and "BTRFS" are therefore wrong spellings in this wiki. -- Kynikos (talk) 09:36, 6 January 2014 (UTC)

Should not suggest to edit files in /usr/share

Section Troubleshooting > GRUB > Missing root suggests to edit /usr/share/grub/grub-mkconfig_lib, which is tracked by the package manager and will be replaced on updates. Shouldn't it be discouraged?

Depau (talk) 10:18, 22 July 2018 (UTC)

Yes, it is discouraged. The right way to fix this issue is to file request in grub bug tracker. As a temporary fix this information can be left with bold indication that overwriring package files is discouraged and file can be overwritten by next update. As additional information: grub is updated rarely (, so for some people discussed solution can be tolerable. P.S. I have no relation with discussed edit and whether the advice actually fixes the bug. --Mxfm (talk) 17:39, 22 July 2018 (UTC)
I filed a request:
I don't know if it fixes the bug either, I was just reading the page and noticed the issue. Maybe the person who wrote the original suggestion should be contacted to see if they're still using this setup and if it can be done in some other, better way. --Depau (talk) 13:21, 23 July 2018 (UTC)
Filing that bug was not a good idea, read Reporting bug guidelines.
The text was added in Special:Diff/267014 by DevotedFollower. Since the section has no references (e.g. to a GRUB bug report), I suggest just removing it.
-- nl6720 (talk) 13:44, 23 July 2018 (UTC)
"to file request in grub bug tracker" - please note, I have written about grub bug tracker, not arch. This is upstream bug (if actually this is a bug) and should be reported there. --Mxfm (talk) 15:12, 23 July 2018 (UTC)

Not suited to small devices

Is it the case to tell people that it is very common to encounter problems difficult to solve at a first glance when using this file system on small partitions? I am referring to 'I ran out of disk space' and 'btrfs claims I am out of space' entries in the btrfs faq, which are very likely to occur after some days of usage and are not very easy to solve when snapshots are involved. Tallero (talk) 19:25, 5 November 2018 (UTC)

Phoronix mount option benchmarking in Btrfs#See also

Would be better to leave only the latest benchmarking. --AlonsoLP (talk) 10:24, 10 March 2019 (UTC)

About "critical bug in 5.2"

About this edit. I beleive the problem is overblown. Please read comment on bugzilla page (copied below).

TL;DR Just one cotributor claimed critical regression and sent a patch which was not reviewed yet.

"Some background and brief description from btrfs mailing list. Approximately in late summer one user started discussion about btrfs data corruption after updating to 5.2. In later June another user reported data corruption after running 5.2 for some time. After fixing his problem the second user continued running 5.2 without issues. His message "I am running 5.2 and everything currently is OK" was sent in late August. This issue seemed to be resolved. Afterwards this discussion switched to relatively separate issue about spurious space cache warnings after running 5.2. Several users said thay they received such space cache warnings (I also found such message in my journal log). One additional user reported data corruption. Some days ago one (not with very high contribution) developer claimed that there is critical regression and proposed a patch.

Please note, that currently there are several reported cases with data corruption after switching to 5.2/running 5.2 for some time. In addition, there are several messages about space cache warnings which do not harm. Kernel 5.2 released some time ago, so the number of btrfs users running 5.2 without any issue is strongly higher than 3. Circumstances and conditions which trigger data corruption are not understood. Proposed patch was not reviewed by now." Mxfm (talk) 19:05, 12 September 2019 (UTC)

IMHO the issue is not an overstatement of the current situation. Btrfs is a filesystem after all and hence errors are of special interest to anyone upgrading his or her system. A single data corruption, even if only occurring with low probability, is worth mentioning. -- Edh (talk) 20:22, 12 September 2019 (UTC)
Agreed - I had plans on adding the warning myself. Several users have confirmed hangs, or even data corruption. Closing -- Alad (talk) 21:52, 12 September 2019 (UTC)
Okay, let the warning stay, but overstatement is obvious.
IMHO the issue is not an overstatement of the current situation. Btrfs is a filesystem after all and hence errors are of special interest to anyone upgrading his or her system But in the article it is written as "serious regression" which was claimed by not a very significant contributor. No other dev has acknowledged critical bug.
Several users have confirmed hangs, or even data corruption Users report corruption in btrfs mailing list once in 2-3 months for many years for different reasons (power loss, bad ram, etc). What made this event special is 1) single contributor called it regression and 2) user Jamespharvey20 has spead that message to Arch bugzilla and wiki. Mxfm (talk) 05:50, 13 September 2019 (UTC)
This was discussed on IRC, including the devops/TU channel, and it was not just "a single contributor" or User:Jamespharvey20. If you want to turn this into some kind of witch hunt, be me guest, just don't expect it to be tolerated on the wiki. The warning stays as is until FS#63733 is fixed, after which a clause can be added for users to upgrade their kernel. -- Alad (talk) 20:34, 13 September 2019 (UTC)
I made a small change to the warning to specify the actual regression, instead of leaving it up to interpretation. [1] -- Alad (talk) 20:54, 13 September 2019 (UTC)
You misunderstood me. I stand for correcting the warning to clarify the risks, because in the bugzilla and in the wiki (initially) it was written like "btrfs developers do not recommend to run 5.2 otherwise you can corrupt data". I provided information why it is overreaction. Nobody provided any arguements/reasons, instead I receive attack on me. Finally you essentially had to agree and to clarify the warning (good of you). I consider current wording is objective, so it can be left in this form. Mxfm (talk) 10:30, 14 September 2019 (UTC)
OK, my bad. Good we all agree now. -- Alad (talk) 12:38, 14 September 2019 (UTC)

New page suggestion: Btrfs Snapshots

The main article Btrfs is already very long but does not cover the tools for working with snapshots, even though some of these tools are already in the repositories, and are popular. E.g. has 400 stars on github and is on the AUR. There is a article about Snapper, that covers some of these tools, but the article about snapper should focus on Snapper itself, and maybe tools based on snapper, but not independent tools. It is also important to show which tools are based on snapper and which tools only require btrfs itself. The Snapper article mixes both tools. -- Teateawhy (talk) 03:03, 11 January 2020 (UTC)

First there should be a draft of the proposed content, then we can decide if it should be a subsection or a subpage. -- Lahwaacz (talk) 07:37, 11 January 2020 (UTC)