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?
- 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)
- 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)
- 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
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. https://github.com/digint/btrbk 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)
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
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)
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.
- 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)
- Better, but my question was more about the part inside the tip, is the line
cp -a /path/to/dir_old/* /path/to/dirstill accurate or will
cprequire a flag to not create a lightweight copy? the tip mentions that
cp --reflinkwon't work, and now lightweight copies are implied by
- Better, but my question was more about the part inside the tip, is the line
Add guidance on how to migrate to new default options
# 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
- If upstream recommends the migration, they should document it themselves. — Lahwaacz (talk) 20:06, 19 November 2021 (UTC)
Suggested edits for swap file section
Imho, the Btrfs#Swap_file section is missing some critical information: it is not described what the best way to create a subvolume for the swap file is. Also, the steps for swap file creation that are linked to use the inefficient dd method for space preallocation. The steps described on the btrfs man page are much better. Therefore, I would like to rewrite that section accordingly. Any objections? Thawn (talk) 11:04, 27 December 2021 (UTC)
the edited section would look like this:
Swap files in Btrfs are supported since Linux kernel 5.0. The proper way to initialize a swap file (see also ) is to first create a non-snapshotted subvolume (for example Template:Id) to host the file, cd into its directory, then create a zero length file, set the
No_COW attribute on it with chattr, and make sure compression is disabled:
# btrfs subvolume create /swap # cd /swap # truncate -s 0 ./swapfile # chattr +C ./swapfile # btrfs property set ./swapfile compression none # fallocate -l 2G swapfile # chmod 600 ./swapfile # mkswap ./swapfile # swapon ./swapfile
Finally, edit the fstab configuration to add an entry for the swap file:
/swapfile none swap <proper options for btrfs?> 0 0
Note that only three commands are similar (but not identical, since the swapfile is in a subfolder where the subvolume is mounted) to the Swap#Swap_file_creation page. Therefore, I suggest to have the full instructions here and change the Swap#Swap_file_creation page to link here in the first note about btrfs and remove the second note about btrfs.
Note that the second note on the Swap#Swap_file_creation page tells us that we should not forget to add the created subvolume to the list as well, and remove the discard,autodefrag and compression options. However, this note conflicts with the btrfs man page which recommends
/path/swapfile none swap defaults 0 0
Which options should we state here?
- The removal of mount options refers to the btrfs (sub)volume mounted via fstab. In my fstab, there's this line:
UUID=<btrfs filesystem UUID> /mnt/swap btrfs <your typical mount options minus discard,autodefrag,compression>,subvolid=<id>,subvol=/<path> 0 0
- The subvolume should be created one way:
# btrfs subvolume create swap
- In my case, I ran this command in a directory called "__active" in my btrfs filesystem's root and ran
# btrfs subvolume list .
- which gave me the result:
ID 256 gen 11643 top level 5 path __active/swap
- So, ID and path should be inserted into the fstab above.
- Afterwards, you simply do the usual, existing steps to create a swapfile within said swap subvolume.
- Yes, you should still use dd! It's the only way to make sure the swap file is a continuous file! Furthermore, with your change, you currently suggest to do no allocation of the swap file at all, which means you have a file of a size of zero, causing mkswap to rightfully tell you:
mkswap: error: swap area needs to be at least 40 KiB
- And finally, the next line to put into fstab is:
/mnt/swap/swapfile none swap 0 0
- KescherArch (talk) 13:14, 27 December 2021 (UTC)
Swap files on Btrfs are supported since Linux 5.0 on files with nocow attribute. See the btrfs(5) manual page for more details.
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.