Arch linux btrfs swapfile

Arch linux btrfs swapfile

This page provides an introduction to swap space and paging on GNU/Linux. It covers creation and activation of swap partitions and swap files.

Linux divides its physical RAM (random access memory) into chunks of memory called pages. Swapping is the process whereby a page of memory is copied to the preconfigured space on the hard disk, called swap space, to free up that page of memory. The combined sizes of the physical memory and the swap space is the amount of virtual memory available.

Support for swap is provided by the Linux kernel and user-space utilities from the util-linux package.

Contents

Swap space

Swap space can take the form of a disk partition or a file. Users may create a swap space during installation or at any later time as desired. Swap space can be used for two purposes, to extend the virtual memory beyond the installed physical memory (RAM), and also for suspend-to-disk support.

If it is beneficial to extend the virtual memory with swap depends on the amount of installed physical memory. If the amount of physical memory is less than the amount of memory required to run all the desired programs, then it may be beneficial to enable swap. This avoids out of memory conditions, where the Linux kernel OOM killer mechanism will automatically attempt to free up memory by killing processes. To increase the amount of virtual memory to the required amount, add the necessary difference (or more) as swap space.

The biggest drawback of enabling swap is its lower performance, see section #Performance. Hence, enabling swap is a matter of personal preference: some prefer programs to be killed over enabling swap and others prefer enabling swap and slower system when the physical memory is exhausted.

To check swap status, use:

Or to show physical memory as well as swap usage:

Swap partition

The factual accuracy of this article or section is disputed.

A swap partition can be created with most GNU/Linux partitioning tools. Swap partitions are typically designated as type 82 . Even though it is possible to use any partition type as swap, it is recommended to use type 82 in most cases since systemd will automatically detect it and mount it (see below).

To set up a partition as Linux swap area, the mkswap(8) command is used. For example:

To enable the device for paging:

To enable this swap partition on boot, add an entry to /etc/fstab :

where the device_UUID is the UUID of the swap space.

See fstab for the file syntax.

Activation by systemd

systemd activates swap partitions based on two different mechanisms. Both are executables in /usr/lib/systemd/system-generators . The generators are run on start-up and create native systemd units for mounts. The first, systemd-fstab-generator , reads the fstab to generate units, including a unit for swap. The second, systemd-gpt-auto-generator inspects the root disk to generate units. It operates on GPT disks only, and can identify swap partitions by their type GUID, see systemd#GPT partition automounting for more information.

Disabling swap

To deactivate specific swap space:

Alternatively use the -a switch to deactivate all swap space.

Since swap is managed by systemd, it will be activated again on the next system startup. To disable the automatic activation of detected swap space permanently, run systemctl —type swap to find the responsible .swap unit and mask it.

Swap file

As an alternative to creating an entire partition, a swap file offers the ability to vary its size on-the-fly, and is more easily removed altogether. This may be especially desirable if disk space is at a premium (e.g. a modestly-sized SSD).

Manually

Swap file creation

Use dd to create a swap file the size of your choosing. For example, creating a 512 MiB swap file:

Set the right permissions (a world-readable swap file is a huge local vulnerability):

After creating the correctly sized file, format it to swap:

Activate the swap file:

Finally, edit the fstab configuration to add an entry for the swap file:

For additional information, see fstab#Usage.

Remove swap file

To remove a swap file, it must be turned off first and then can be removed:

Finally remove the relevant entry from /etc/fstab .

Automated

zram-generator

The aim of this tool is the creation of zram devices. It is written in Rust and resides in systemd’s GitHub. It can be installed with the zram-generator package. Configuration is straightforward and explained in the README.

systemd-swap

systemd-swap is a script for creating hybrid swap space from zram swaps, swap files and swap partitions. It is not affiliated with the systemd project.

Install the systemd-swap package. Uncomment and set swapfc_enabled=1 in the Swap File Chunked section of /etc/systemd/swap.conf . Start/enable the systemd-swap service.

Visit the authors GitHub page for more information and setting up the recommended configuration.

Swap encryption

Performance

Swap operations are usually significantly slower than directly accessing data in RAM. Disabling swap entirely to improve performance can sometimes lead to a degradation, since it decreases the memory available for VFS caches, causing more frequent and costly disk I/O.

Swap values can be adjusted to help performance:

Swappiness

The swappiness sysctl parameter represents the kernel’s preference (or avoidance) of swap space. Swappiness can have a value between 0 and 200 (max 100 if Linux /sys/fs/cgroup/memory/memory.swappiness or /proc/sys/vm/swappiness can be read in order to obtain the raw integer value.

To temporarily set the swappiness value:

To set the swappiness value permanently, create a sysctl.d(5) configuration file. For example:

To test and more on why this may work, take a look at this article.

VFS cache pressure

Another sysctl parameter that affects swap performance is vm.vfs_cache_pressure , which controls the tendency of the kernel to reclaim the memory which is used for caching of VFS caches, versus pagecache and swap. Increasing this value increases the rate at which VFS caches are reclaimed[1]. For more information, see the Linux kernel documentation.

Priority

If you have more than one swap file or swap partition you should consider assigning a priority value (0 to 32767) for each swap area. The system will use swap areas of higher priority before using swap areas of lower priority. For example, if you have a faster disk ( /dev/sda ) and a slower disk ( /dev/sdb ), assign a higher priority to the swap area located on the fastest device. Priorities can be assigned in fstab via the pri parameter:

Or via the —priority parameter of swapon:

If two or more areas have the same priority, and it is the highest priority available, pages are allocated on a round-robin basis between them.

Using zswap or zram

Zswap is a Linux kernel feature providing a compressed write-back cache for swapped pages. This increases the performance and decreases the IO-Operations. ZRAM creates a virtual compressed Swap-file in memory as alternative to a swapfile on disk.

Striping

There is no necessity to use RAID for swap performance reasons. The kernel itself can stripe swapping on several devices, if you just give them the same priority in the /etc/fstab file. Refer to The Software-RAID HOWTO for details.

Источник

Arch Linux

You are not logged in.

#1 2019-06-08 10:52:52

[SOLVED] Swapfile on BTRFS filesystem with compression enabled

I’ve recently set up a system with two SSDs, with LUKS partions formatted with Btrfs RAID0, in which I have top-level subvolumes for @root, @home, @backups, and @swap. As might be obvious, my plan was to mount @root to /, @home to /home, @backups to /backups, and @swap to /swap. My /etc/fstab is below:

As I’ve found out via the Btrfs Wiki, and as mentioned in Arch’s own Wiki, one cannot mount different subvolumes of the same file system with different Btrfs-specific mount options, namely nodatacow and compress=zstd.

Since Btrfs swapfiles cannot be on a filesystem with CoW or compress, the Arch Wiki’s suggestion is to use chattr +C to turn of CoW and btrfs property set /swapfile compression none to turn off compression on the individual file to be used as the swapfile before allocating blocks to it (in the Wiki example, «/swapfile»).

I’m having no luck with this, and I’m wondering if it’s because even though I’ve set the nodatacow flag with chattr, and the no conmpression flag with the btrfs command:

the @swap subvolume is still mounted with the compress option turned on. I’ve followed the steps exactly, with no errors showing, right up until I try to use swapon at which point I get:

Contrary to what’s in the Wiki, are swapfiles not supported on Btrfs filesystems mounted with a compression flag, even if CoW and compression are turned off for the file individually? Has anyone had any success with a similar setup?

Last edited by woodape (2019-06-09 05:41:24)

#2 2019-06-08 12:26:48

Re: [SOLVED] Swapfile on BTRFS filesystem with compression enabled

Did you run «mkswap filename» to format the swap file?

You don’t need to worry about compression because «nodatacow» is already forcing compression off as a side-effect. The reason is that compression makes parts of a file randomly change size, and that’s not possible to manage on the real disk without CoW. You also don’t need to do «btrfs property set . «, just that «chattr +C» you used is already enough.

#3 2019-06-08 14:21:26

Re: [SOLVED] Swapfile on BTRFS filesystem with compression enabled

Thanks for the reply Ropid, yes I did run mkswap on the file. I have just put all the commands from the wiki into the following bash script called make_a_swap_file:

and as root I’ve run ./make_a_swap_file &> log, and here are the contents of log

Which indicates the file was created, has the nodatacow attribute, and successfully formatted as a swap file. But the swapon command fails with «invalid argument», which Btrfs users before kernel 5.0 have observed as meaning the filesystem isn’t supported. I’m running the lastest kernel, 5.1.7-arch1-ARCH.

There’s no difference if I exclude the btrfs . command. Have you tried making a swapfile on a btrfs filesystem mounted with compression and CoW turned on? Does it work for you?

#4 2019-06-08 19:42:24

Re: [SOLVED] Swapfile on BTRFS filesystem with compression enabled

In your script, you are working inside the «/» subvolume, not inside the «/swap» subvolume. Can you try changing things around so that the lines in the script all work on a file named «/swap/swapfile» instead of the current «/swapfile», and then see what happens?

#5 2019-06-08 20:50:08

Re: [SOLVED] Swapfile on BTRFS filesystem with compression enabled

Contrary to what’s in the Wiki, are swapfiles not supported on Btrfs filesystems mounted with a compression flag, even if CoW and compression are turned off for the file individually? Has anyone had any success with a similar setup?

Just making a file NOCOW does not help, swap file support relies on one function that btrfs intentionally does not implement due to potential corruptions.

#6 2019-06-09 04:39:15

Re: [SOLVED] Swapfile on BTRFS filesystem with compression enabled

Ropid, just did the change and the result is the same. The swapfile is created, formatted, and set to nodatacow, but I get «Invalid argument» with swapon. I’m going to do some tests with a couple of usb-drives and report back.

latalante1, when quoting it’s useful to provide the full context of the quote. Here is the section from the btrfs wiki (which I link to in my OP):

From kernel 5.0+ btrfs have native swap files support, but with some limitations. Swap file — must be fully allocated as NOCOW with no compression on one device.

For kernels before 5.0, swap files not supported. Just making a file NOCOW does not help, swap file support relies on one function that btrfs intentionally does not implement due to potential corruptions. The swap implementation used to rely on some assumptions which may not hold in btrfs, like block numbers in the swap file while btrfs has a different block number mapping in case of multiple devices. There is a new API that could be used to port swap to btrfs; for more details have a look at project ideas#Swap file support.

I read that as saying that «Just making a file NOCOW. » applies to kernels before 5.0. This also seems to be the interpretation of whoever wrote the swapfile section of the Arch Wiki, which is the Wiki I’m referring to where you quote me. Are you agreeing that the Arch Wiki may be incorrect?

Last edited by woodape (2019-06-09 04:52:52)

Источник

Btrfs

Btrfs is a modern copy on write (CoW) filesystem for Linux aimed at implementing advanced features while also focusing on fault tolerance, repair and easy administration. Jointly developed at multiple companies, Btrfs is licensed under the GPL and open for contribution from anyone.

Contents

Preparation

For user space utilities install the btrfs-progs package, which is required for basic operations.

If you need to boot from a Btrfs file system (i.e., your kernel and initramfs reside on a Btrfs partition), check if your boot loader supports Btrfs.

File system creation

The following shows how to create a new Btrfs file system. To convert an ext3/4 partition to Btrfs, see #Ext3/4 to Btrfs conversion. To use a partitionless setup, see #Partitionless Btrfs disk.

See mkfs.btrfs(8) for more information.

File system on a single device

To create a Btrfs filesystem on partition /dev/partition :

The Btrfs default nodesize for metadata is 16KB, while the default sectorsize for data is equal to page size and autodetected. To use a larger nodesize for metadata (must be a multiple of sectorsize, up to 64KB is allowed), specify a value for the nodesize via the -n switch as shown in this example using 32KB blocks:

Multi-device file system

Multiple devices can be used to create a RAID. Supported RAID levels include RAID 0, RAID 1, RAID 10, RAID 5 and RAID 6. Starting from kernel 5.5 RAID1c3 and RAID1c4 for 3- and 4- copies of RAID 1 level. The RAID levels can be configured separately for data and metadata using the -d and -m options respectively. By default the data has one copy ( single ) and the metadata is mirrored ( raid1 ). This is similar to creating a JBOD configuration, where disks are seen as one filesystem, but files are not duplicated. See Using Btrfs with Multiple Devices for more information about how to create a Btrfs RAID volume.

You must include either the udev hook or the btrfs hook in /etc/mkinitcpio.conf in order to use multiple Btrfs devices in a pool. See the Mkinitcpio#Common hooks article for more information.

See #RAID for advice on maintenance specific to multi-device Btrfs file systems.

Configuring the file system

Copy-on-Write (CoW)

By default, Btrfs uses copy-on-write for all files all the time. Writes do not overwrite data in place; instead, a modified copy of the block is written to a new location, and metadata is updated to point at the new location. See the Btrfs Sysadmin Guide section for implementation details, as well as advantages and disadvantages.

Disabling CoW

To disable copy-on-write for newly created files in a mounted subvolume, use the nodatacow mount option. This will only affect newly created files. Copy-on-write will still happen for existing files. The nodatacow option also disables compression. See btrfs(5) for details.

To disable copy-on-write for single files/directories do:

This will disable copy-on-write for those operation in which there is only one reference to the file. If there is more than one reference, e.g. due to file clones / lightweight clones or filesystem snapshots, copy-on-write still occurs. Note that as of coreutils 9.0, cp attempts to perform lightweight copies by default—see cp(1) for more details.

Compression

Btrfs supports transparent and automatic compression. This reduces the size of files as well as significantly increases the lifespan of flash-based media by reducing write amplification. See Fedora:Changes/BtrfsByDefault#Compression, [1], and [2]. It can also improve performance, in some cases (e.g. single thread with heavy file I/O), while obviously harming performance in other cases (e.g. multi-threaded and/or CPU intensive tasks with large file I/O). Better performance is generally achieved with the fastest compress algorithms, zstd and lzo, and some benchmarks provide detailed comparisons.

The compress=alg mount option enables automatically considering every file for compression, where alg is either zlib , lzo , zstd , or no (for no compression). Using this option, btrfs will check if compressing the first portion of the data shrinks it. If it does, the entire write to that file will be compressed. If it does not, none of it is compressed. With this option, if the first portion of the write does not shrink, no compression will be applied to the write even if the rest of the data would shrink tremendously. [3] This is done to prevent making the disk wait to start writing until all of the data to be written is fully given to btrfs and compressed.

The compress-force=alg mount option can be used instead, which makes btrfs skip checking if compression shrinks the first portion, and enables automatic compression try for every file. In a worst-case scenario, this can cause (slightly) more CPU usage for no purpose. However, empirical testing on multiple mixed-use systems showed a significant improvement of about 10% disk compression from using compress-force=zstd over just compress=zstd , which also had 10% disk compression.

Only files created or modified after the mount option is added will be compressed.

To apply compression to existing files, use the btrfs filesystem defragment -calg command, where alg is either zlib , lzo or zstd . For example, in order to re-compress the whole file system with zstd , run the following command:

To enable compression when installing Arch to an empty Btrfs partition, use the compress option when mounting the file system: mount -o compress=zstd /dev/sdxY /mnt/ . During configuration, add compress=zstd to the mount options of the root file system in fstab.

View compression types and ratios

compsize takes a list of files (or an entire btrfs filesystem) and measures compression types used and effective compression ratios. Uncompressed size may not match the number given by other programs such as du(1) , because every extent is counted once, even if it is reflinked several times, and even if part of it is no longer used anywhere but has not been garbage collected. The -x option keeps it on a single filesystem, which is useful in situations like compsize -x / to avoid it from attempting to look in non-btrfs subdirectories and fail the entire run.

Subvolumes

This article or section is a candidate for merging with User:I2Oc9/Btrfs_subvolumes.

«A btrfs subvolume is not a block device (and cannot be treated as one) instead, a btrfs subvolume can be thought of as a POSIX file namespace. This namespace can be accessed via the top-level subvolume of the filesystem, or it can be mounted in its own right.» [4]

Each Btrfs file system has a top-level subvolume with ID 5. It can be mounted as / (by default), or another subvolume can be mounted instead. Subvolumes can be moved around in the filesystem and are rather identified by their id than their path.

See the following links for more details:

Creating a subvolume

To create a subvolume:

Listing subvolumes

To see a list of current subvolumes and their ids under path :

Deleting a subvolume

To delete a subvolume:

Since Linux 4.18, one can also delete a subvolume like a regular directory ( rm -r , rmdir ).

Mounting subvolumes

Subvolumes can be mounted like file system partitions using the subvol=/path/to/subvolume or subvolid=objectid mount flags. For example, you could have a subvolume named subvol_root and mount it as / . One can mimic traditional file system partitions by creating various subvolumes under the top level of the file system and then mounting them at the appropriate mount points. Thus one can easily restore a file system (or part of it) to a previous state using #Snapshots.

See the Btrfs Wiki FAQ for which mount options can be used per subvolume.

See btrfs(5) for a full list of btrfs-specific mount options.

Mounting subvolume as root

To use a subvolume as the root mountpoint specify the subvolume via a kernel parameter using rootflags=subvol=/path/to/subvolume . Edit the root mountpoint in /etc/fstab and specify the mount option subvol= . Alternatively the subvolume can be specified with its id, rootflags=subvolid=objectid as kernel parameter and subvolid=objectid as mount option in /etc/fstab .

Changing the default sub-volume

The default sub-volume is mounted if no subvol= mount option is provided. To change the default subvolume, do:

where subvolume-id can be found by listing.

Changing the default subvolume with btrfs subvolume set-default will make the top level of the filesystem inaccessible, except by use of the subvol=/ or subvolid=5 mount options [5].

Quota

Quota support in Btrfs is implemented at a subvolume level by the use of quota groups or qgroup: Each subvolume is assigned a quota groups in the form of 0/subvolume_id by default. However it is possible to create a quota group using any number if desired.

To use qgroups you need to enable quota first using

From this point onwards newly created subvolumes will be controlled by those groups. In order to retrospectively enable them for already existing subvolumes, enable quota normally, then create a qgroup (quota group) for each of those subvolume using their subvolume_id and rescan them:

Quota groups in Btrfs form a tree hierarchy, whereby qgroups are attached to subvolumes. The size limits are set per qgroup and apply when any limit is reached in tree that contains a given subvolume.

Limits on quota groups can be applied either to the total data usage, un-shared data usage, compressed data usage or both. File copy and file deletion may both affect limits since the unshared limit of another qgroup can change if the original volume’s files are deleted and only one copy is remaining. For example a fresh snapshot shares almost all the blocks with the original subvolume, new writes to either subvolume will raise towards the exclusive limit, deletions of common data in one volume raises towards the exclusive limit in the other one.

To apply a limit to a qgroup, use the command btrfs qgroup limit . Depending on your usage either use a total limit, unshared limit ( -e ) or compressed limit ( -c ). To show usage and limits for a given path within a filesystem use

Commit interval

The resolution at which data are written to the filesystem is dictated by Btrfs itself and by system-wide settings. Btrfs defaults to a 30 seconds checkpoint interval in which new data are committed to the filesystem. This can be changed by appending the commit mount option in /etc/fstab for the btrfs partition.

System-wide settings also affect commit intervals. They include the files under /proc/sys/vm/* and are out-of-scope of this wiki article. The kernel documentation for them is available at https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html.

SSD TRIM

A Btrfs filesystem is able to free unused blocks from an SSD drive supporting the TRIM command. Starting with kernel version 5.6 there is asynchronous discard support, enabled with mount option discard=async . Freed extents are not discarded immediately, but grouped together and trimmed later by a separate worker thread, improving commit latency.

More information about enabling and using TRIM can be found in Solid State Drives#TRIM.

Usage

Swap file

Swap files in Btrfs are supported since Linux kernel 5.0.[6] The proper way to initialize a swap file is to first create a non-snapshotted subvolume 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:

Displaying used/free space

General linux userspace tools such as df(1) will inaccurately report free space on a Btrfs partition. It is recommended to use btrfs filesystem usage to query Btrfs partitions. For example, for a full breakdown of device allocation and usage stats:

Alternatively, btrfs filesystem df allows a quick check on usage of allocated space without the requirement to run as root:

See [7] for more information.

The same limitations apply to tools which analyze space usage for some subset of the filesystem, such as du(1) or ncdu(1) , as they do not take into account reflinks, snapshots and compression. Instead, see btdu AUR and compsize for btrfs-aware alternatives.

Defragmentation

Btrfs supports online defragmentation through the mount option autodefrag , see btrfs(5) § MOUNT OPTIONS . To manually defragment your root, use:

Using the above command without the -r switch will result in only the metadata held by the subvolume containing the directory being defragmented. This allows for single file defragmentation by simply specifying the path.

Defragmenting a file which has a COW copy (either a snapshot copy or one made with cp or bcp) plus using the -c switch with a compression algorithm may result in two unrelated files effectively increasing the disk usage.

Btrfs offers native «RAID» for #Multi-device file systems. Notable features which set btrfs RAID apart from mdadm are self-healing redundant arrays and online balancing. See the Btrfs wiki page for more information. The Btrfs sysadmin page also has a section with some more technical background.

Scrub

This article or section needs expansion.

The Btrfs Wiki Glossary says that Btrfs scrub is «[a]n online filesystem checking tool. Reads all the data and metadata on the filesystem, and uses checksums and the duplicate copies from RAID storage to identify and repair any corrupt data.»

Start manually

To start a (background) scrub on the filesystem which contains / :

To check the status of a running scrub:

Start with a service or timer

The btrfs-progs package brings the btrfs-scrub@.timer unit for monthly scrubbing the specified mountpoint. Enable the timer with an escaped path, e.g. btrfs-scrub@-.timer for / and btrfs-scrub@home.timer for /home . You can use systemd-escape -p /path/to/mountpoint to escape the path, see systemd-escape(1) for details.

You can also run the scrub by starting btrfs-scrub@.service (with the same encoded path). The advantage of this over btrfs scrub (as the root user) is that the results of the scrub will be logged in the systemd journal.

On large NVMe drives with insufficient cooling (e.g. in a laptop), scrubbing can read the drive fast enough and long enough to get it very hot. If you are running scrubs with systemd, you can easily limit the rate of scrubbing with the IOReadBandwidthMax option described in systemd.resource-control(5) by using a drop-in file.

Balance

«A balance passes all data in the filesystem through the allocator again. It is primarily intended to rebalance the data in the filesystem across the devices when a device is added or removed. A balance will regenerate missing copies for the redundant RAID levels, if a device has failed.» [8] See Upstream FAQ page.

On a single-device filesystem a balance may be also useful for (temporarily) reducing the amount of allocated but unused (meta)data chunks. Sometimes this is needed for fixing «filesystem full» issues.

Snapshots

«A snapshot is simply a subvolume that shares its data (and metadata) with some other subvolume, using btrfs’s COW capabilities.» See Btrfs Wiki SysadminGuide#Snapshots for details.

To create a snapshot:

To create a readonly snapshot add the -r flag. To create writable version of a readonly snapshot, simply create a snapshot of it.

Send/receive

A subvolume can be sent to stdout or a file using the send command. This is usually most useful when piped to a Btrfs receive command. For example, to send a snapshot named /root_backup (perhaps of a snapshot you made of / earlier) to /backup you would do the following:

The snapshot that is sent must be readonly. The above command is useful for copying a subvolume to an external device (e.g. a USB disk mounted at /backup above).

You can also send only the difference between two snapshots. For example, if you have already sent a copy of root_backup above and have made a new readonly snapshot on your system named root_backup_new , then to send only the incremental difference to /backup do:

Now a new subvolume named root_backup_new will be present in /backup .

See Btrfs Wiki’s Incremental Backup page on how to use this for incremental backups and for tools that automate the process.

Deduplication

Using copy-on-write, Btrfs is able to copy files or whole subvolumes without actually copying the data. However whenever a file is altered a new proper copy is created. Deduplication takes this a step further, by actively identifying blocks of data which share common sequences and combining them into an extent with the same copy-on-write semantics.

Tools dedicated to deduplicate a Btrfs formatted partition include duperemove , bees , bedup AUR and btrfs-dedup. One may also want to merely deduplicate data on a file based level instead using e.g. rmlint , jdupes AUR or dduper-git AUR . For an overview of available features of those programs and additional information have a look at the upstream Wiki entry.

Furthermore Btrfs developers are working on inband (also known as synchronous or inline) deduplication, meaning deduplication done when writing new data to the filesystem. Currently it is still an experiment which is developed out-of-tree. Users willing to test the new feature should read the appropriate kernel wiki page.

Known issues

A few limitations should be known before trying.

Encryption

Btrfs has no built-in encryption support, but this may come in the future. Users can encrypt the partition before running mkfs.btrfs . See dm-crypt/Encrypting an entire system#Btrfs subvolumes with swap.

Existing Btrfs file systems can use something like EncFS or TrueCrypt, though perhaps without some of Btrfs’ features.

btrfs check issues

The tool btrfs check has known issues and should not be run without further reading, see section #btrfs check.

Tips and tricks

Partitionless Btrfs disk

Btrfs can occupy an entire data storage device, replacing the MBR or GPT partitioning schemes, using subvolumes to simulate partitions. However, using a partitionless setup is not required to simply create a Btrfs filesystem on an existing partition that was created using another method. There are some limitations to partitionless single disk setups:

• Cannot place other file systems on another partition on the same disk.
• If using a Linux kernel version before 5.0, you cannot use swap area as Btrfs did not support swap files pre-5.0 and there is no place to create swap partition
• Cannot use UEFI to boot.

To overwrite the existing partition table with Btrfs, run the following command:

For example, use /dev/sda rather than /dev/sda1 . The latter would format an existing partition instead of replacing the entire partitioning scheme. Because the root partition is Btrfs, make sure btrfs is compiled into the kernel, or put btrfs into mkinitcpio.conf#MODULES and regenerate the initramfs.

Install the boot loader like you would for a data storage device with a Master Boot Record. See Syslinux#Manual install or GRUB/Tips and tricks#Install to partition or partitionless disk. If your kernel does not boot due to Failed to mount /sysroot. , please add GRUB_PRELOAD_MODULES=»btrfs» in /etc/default/grub and generate the grub configuration (GRUB#Generate the main configuration file).

Ext3/4 to Btrfs conversion

Boot from an install CD, then convert by doing:

Mount the partion and test the conversion by checking the files. Be sure to change the /etc/fstab to reflect the change (type to btrfs and fs_passno [the last field] to 0 as Btrfs does not do a file system check on boot). Also note that the UUID of the partition will have changed, so update fstab accordingly when using UUIDs. chroot into the system and rebuild your bootloaders menu list (see Install from existing Linux). If converting a root filesystem, while still chrooted run mkinitcpio -p linux to regenerate the initramfs or the system will not successfully boot.

After confirming that there are no problems, complete the conversion by deleting the backup ext2_saved sub-volume. Note that you cannot revert back to ext3/4 without it.

Finally balance the file system to reclaim the space.

Remember that some applications which were installed prior have to be adapted to Btrfs.

Checksum hardware acceleration

The factual accuracy of this article or section is disputed.

CRC32 is a new instruction in Intel SSE4.2. To verify if Btrfs checksum is hardware accelerated:

If you see crc32c=crc32c-generic , it is probably because your root partition is Btrfs, and you will have to compile crc32c-intel into the kernel to make it work. Putting crc32c-intel into mkinitcpio.conf does not work.

Corruption recovery

btrfs-check cannot be used on a mounted file system. To be able to use btrfs-check without booting from a live USB, add it to the initial ramdisk:

Then if there is a problem booting, the utility is available for repair.

See the Btrfs Wiki page for more information.

Booting into snapshots

In order to boot into a snapshot, the same procedure applies as for mounting a subvolume as your root parition, as given in section mounting a subvolume as your root partition, because snapshots can be mounted like subvolumes.

• If using GRUB you can automatically populate your boot menu with btrfs snapshots when regenerating the configuration file with the help of grub-btrfs or grub-btrfs-gitAUR .
• If using rEFInd you can automatically populate your boot menu with btrfs snapshots with the help of refind-btrfsAUR , after enabling refind-btrfs.service .

Use Btrfs subvolumes with systemd-nspawn

Reducing access time metadata updates

Because of the copy-on-write nature of Btrfs simply accessing files can trigger the metadata copy and writing. Reducing the frequency of access time updates may eliminate this unexpected disk usage and increase performance. See fstab#atime options for the available options.

Troubleshooting

See the Btrfs Problem FAQ for general troubleshooting.

Partition offset

The offset problem may happen when you try to embed core.img into a partitioned disk. It means that it is OK to embed GRUB’s core.img into a Btrfs pool on a partitionless disk (e.g. /dev/sdX ) directly.

GRUB can boot Btrfs partitions, however the module may be larger than other file systems. And the core.img file made by grub-install may not fit in the first 63 sectors (31.5KiB) of the drive between the MBR and the first partition. Up-to-date partitioning tools such as fdisk and gdisk avoid this issue by offsetting the first partition by roughly 1MiB or 2MiB.

Missing root

The factual accuracy of this article or section is disputed.

Users experiencing the following: error no such device: root when booting from a RAID style setup then edit /usr/share/grub/grub-mkconfig_lib and remove both quotes from the line echo » search —no-floppy —fs-uuid —set=root $ $» . Regenerate the config for grub and the system should boot without an error.

Mounting timed out

Sometimes, especially with large RAID1 arrays, mounting might time out during boot with a journal message such as:

This can easily be worked around by providing a longer timeout via the systemd-specific mount option x-systemd.mount-timeout in fstab. For example:

BTRFS: open_ctree failed

As of November 2014 there seems to be a bug in systemd or mkinitcpio causing the following error on systems with multi-device Btrfs filesystem using the btrfs hook in mkinitcpio.conf :

A workaround is to remove btrfs from the HOOKS array in /etc/mkinitcpio.conf and instead add btrfs to the MODULES array. Then regenerate the initramfs and reboot.

You will get the same error if you try to mount a raid array without one of the devices. In that case you must add the degraded mount option to /etc/fstab . If your root resides on the array, you must also add rootflags=degraded to your kernel parameters.

As of August 2016, a potential workaround for this bug is to mount the array by a single drive only in /etc/fstab , and allow btrfs to discover and append the other drives automatically. Group-based identifiers such as UUID and LABEL appear to contribute to the failure. For example, a two-device RAID1 array consisting of ‘disk1′ and disk2’ will have a UUID allocated to it, but instead of using the UUID, use only /dev/mapper/disk1 in /etc/fstab . For a more detailed explanation, see the following blog post.

Another possible workaround is to remove the udev hook in mkinitcpio.conf and replace it with the systemd hook. In this case, btrfs should not be in the HOOKS or MODULES arrays.

See the original forums thread and FS#42884 for further information and discussion.

btrfs check

The btrfs check command can be used to check or repair an unmounted Btrfs filesystem. However, this repair tool is still immature and not able to repair certain filesystem errors even those that do not render the filesystem unmountable.

Источник