Talk:Btrfs

From ArchWiki
Latest comment: 29 May by Phoenix324 in topic How to use `btrfs check` without using live-cd?
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)Reply

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)Reply

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 (https://github.com/archlinux/svntogit-packages/commits/packages/grub/trunk), 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)Reply
I filed a request: https://bugs.archlinux.org/task/59426
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)Reply
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)Reply
"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)Reply

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)Reply

Incremental snapshot when parent snapshot is lost

I'm not completely sure in which section this would fit, maybe under tips-and-tricks, but it's too niche for that. Maybe under troubleshooting, but it's not really a problem. I just want to document how to solve this issue so that others can use it if they are in the same situation as me.

Normally the way to send incremental snapshots is using

btrfs send -p $parent_snapshot $snapshot | btrfs receive /mnt/btr_backup

However when for some reason you have lost your parent snapshot on the sending system this method is no longer possible.

The trivial solution of sending the entire snapshot without using the incremental feature works, but is inefficient in terms of transmission time, bandwidth, and the new storage is not deduplicated.

Another solution is to follow the steps below:

Suppose the snapshot is created on system A and should be sent to system or disk B

1. Create a snapshot of the last snapshot on B with the name of the snapshot to send

sudo btrfs sub snap $current_snapshot $new_snapshot

2. Set snapshot to read-write

sudo btrfs property set -ts $new_snapshot ro false

3. rsync the snapshot from A to B

sudo rsync -avxHAX --delete --progress /path/to/$new_snapshot/ $new_snapshot/

4. Find the UUID of the snapshot at A

sudo btrfs show /path/to/$new_snapshot

5. Set the Received UUID of the new shapshot on B using set_received_uuid.py

sudo set_received_uuid.py $uuid 0 0.0 $new_snapshot

—This unsigned comment is by JJK (talk) 18:04, 30 May 2020‎. Please sign your posts with ~~~~!

Consider removing the mention about nodesize?

In the section about creating btrfs, it talked about nodesize and how to change it. This leads to many newcomers somehow misbelieve that btrfs have a "block size" of 16K (without understanding the difference between nodesize and "block size" / sectorsize). Historically mkfs.btrfs use a default nodesize of 4K and that leads to a lot discussion about under-utilizing the metadata space for a lots of inlined files with max_inline=2K, I guess this is the reason about this page talking about nodesize. This is no longer true as the default nodesize is now 16K and should work well for most people. Farseerfc (talk) 05:42, 15 October 2020 (UTC)Reply

Checksum hardware acceleration - misleading info should be removed

I am using Btrfs as root partition filesystem, and I checked whether the claim of "If you see crc32c=crc32c-generic, it is probably because your root partition is Btrfs" made at Checksum hardware acceleration applies at all. It doesn't for any of the linux kernel packages in the Arch repos, for none of my machines with such a setup. In my opinion, the claim of crc32c-intel having to be compiled into the kernel should be removed, as well as the claim of it being because one's root partition is Btrfs.

KescherArch (talk) 13:17, 23 August 2021 (UTC)Reply

The section was removed, closing. — Lahwaacz (talk) 11:09, 14 August 2023 (UTC)Reply
I think the section itself is still useful. Because, as the linked post states, /sys/fs/btrfs/UUID/checksum should provide a valid info.
Hanabishi (talk) 11:58, 14 August 2023 (UTC)Reply
Is there a system with hardware that supports SSE4.2 instructions but the software is still using the crc32c-generic module? Otherwise I really don't see the value of checking, since you would have to buy a new CPU to "enable" hardware-accelerated checksum. — Lahwaacz (talk) 12:43, 14 August 2023 (UTC)Reply
Well, this is technically possible if the module does not load for some reason. Most probably using unofficial/custom kernels. But yeah, such scenarios are out of scope of the wiki, I guess.
Hanabishi (talk) 13:10, 14 August 2023 (UTC)Reply
But actually considering that crc32c-intel should be loaded before the filesystem mounted, there may be issues when btrfs used as a root partition, because the module should be present inside initramfs.
I just checked and mkinitcpio does include crc32c-intel by default. It is hard to tell how likely misconfiguration may occur, also alternative initramfs generators (dracut and Booster) exist.
So maybe it is worth mentioning after all.
Hanabishi (talk) 14:07, 14 August 2023 (UTC)Reply
If I understand the comments in the bug report, in such cases it should switch to using crc32c-intel later on at runtime. Not having hardware accelerated checksums for the duration of the boot does not really matter. — Lahwaacz (talk) 15:17, 14 August 2023 (UTC)Reply
It doesn't. Quote from https://btrfs.readthedocs.io/en/latest/Checksumming.html:
The accelerated versions are however provided by the modules and must be loaded explicitly before mounting the filesystem to make use of them. You can check in /sys/fs/btrfs/FSID/checksum which one is used.
I also checked it myself and can confirm that it does not switch in runtime.
Hanabishi (talk) 16:06, 14 August 2023 (UTC)Reply

Disabling CoW

Is Btrfs#Disabling CoW still accurate with coreutils 9.0 creating lightweight copies by default ? --Cvlc (talk) 16:25, 27 September 2021 (UTC)Reply

The section used the term "copy-on-write" in a somewhat ambiguous manner; I tried to clarify it, does that help? --CyberShadow (talk) 16:36, 27 September 2021 (UTC)Reply
Better, but my question was more about the part inside the tip, is the line cp -a /path/to/dir_old/* /path/to/dir still accurate or will cp require a flag to not create a lightweight copy? the tip mentions that cp --reflink won't work, and now lightweight copies are implied by cp--Cvlc (talk)
Ah, I didn't get that far. I understand you need to opt out with cp --reflink=never now, updated. --CyberShadow (talk) 05:52, 28 September 2021 (UTC)Reply

Add guidance on how to migrate to new default options

btrfs-progs 5.15 has new defaults for mkfs. How about adding a section which keeps track of current upstream recommended defaults and gives guidance on how to migrate ? From Reddit (needs double-checking):

  • no-holes
# btrfstune -n device
  • free-space-tree (space_cache v2)
# btrfs check --clear-space-cache v1 device
  • DUP for metadata unconditionally
# btrfs balance start -mconvert=dup device

--Cvlc (talk) 18:07, 17 November 2021 (UTC)Reply

If upstream recommends the migration, they should document it themselves. — Lahwaacz (talk) 20:06, 19 November 2021 (UTC)Reply

Why the warning in Btrfs#Partitionless_Btrfs_disk?

The mentioned section starts off with a vague but threatening warning:

> Most users do not want this type of setup and instead should install Btrfs on a regular partition. Furthermore, GRUB strongly discourages installation to a partitionless disk.

The first sentence raises more questions than it answers:

1. Why do most users not want this setup?

2. In what cases is one or the other more appropriate?

The second sentence is weird because not everyone uses GRUB. Furthermore, not everyone will boot from the partition in question. If no one disagrees, I'll delete the sentence.

I think the answers to the above questions may have something to do with alignment of file system data to disk sectors, but I don't know for sure. Neven (talk) 18:55, 3 May 2022 (UTC)Reply

The limitations are explained in the section. The warning is there to make sure people think before going with this setup. It is better to avoid surprises than having to redo all formatting and risking data loss. — Lahwaacz (talk) 09:02, 7 May 2022 (UTC)Reply

Mount options?

Any recommendations for mount options to improve performance? All other filesystem articles have this section, but Btrfs doesn't. Cont999 (talk) 21:52, 8 September 2022 (UTC)Reply

You could trynoatime and to improve it marginally, disabling compression or switching to a less CPU-intensive compression algorhythm. KernelSizedBytes (talk) 18:31, 17 October 2023 (UTC)Reply

How to use `btrfs check` without using live-cd?

section 6.3 advises to add `btrfs` to initram. But how do we use it? How to boot into the mode where i can run `btrfs check`.


I tried rescue and emergency mode from systemd, but both mounts btrfs as `rw`. Phoenix324 (talk) 10:50, 29 May 2024 (UTC)Reply