注意:

The Funtoo Linux project has transitioned to "Hobby Mode" and this wiki is now read-only.

Difference between revisions of "User:Mrl5/Btrfs"

From Funtoo
Jump to navigation Jump to search
((vol.1) proposed improvement of official Btrfs page)
((vol.2) btrfs as root filesystem)
Line 11: Line 11:


<!--T:4-->
<!--T:4-->
It is easy to set up and use btrfs. In this simple introduction, we're going to set up btrfs under Funtoo Linux using an existing {{c|debian-sources}} or {{c|debian-sources-lts}} kernel, like the one that comes pre-built for you with Funtoo Linux, and we will also be using our btrfs storage pool for storing data that isn't part of the Funtoo Linux installation itself. Funtoo Linux will boot from a non-btrfs filesystem, and as part of the initialization process will initialize our btrfs storage and mount it at the location of our choice.
It is easy to set up and use btrfs. In this simple introduction, we're going to set up btrfs as a Funtoo Linux installation root filesystem but this guide can also be applied to other usecases like using btrfs storage pool for storing data that isn't part of the Funtoo Linux installation itself.


== Installation == <!--T:5-->
== Installation == <!--T:5-->

Revision as of 20:49, August 29, 2022

Btrfs is a file system based on the copy-on-write (COW) principle, initially designed at Oracle Corporation for use in Linux. The development of btrfs began in 2007, and since August 2014 the file system's on-disk format has been marked as stable.

The Funtoo Linux project recommends btrfs as a next-generation filesystem, particularly for use in production.

Btrfs is intended to address the lack of pooling, snapshots, checksums, and integral multi-device spanning in Linux file systems.

It is easy to set up and use btrfs. In this simple introduction, we're going to set up btrfs as a Funtoo Linux installation root filesystem but this guide can also be applied to other usecases like using btrfs storage pool for storing data that isn't part of the Funtoo Linux installation itself.

Installation

Enabling btrfs support is as simple as enabling the btrfs mix-in and running a world update:

root # epro mix-in +btrfs
root # emerge -uDN @world

Btrfs is now ready for use.

Btrfs Concepts

Btrfs can be used to manage the physical disks that it uses, and physical disks are added to a Btrfs volume. Then, BTRFS can create subvolumes from the volume on which files can be stored.

Unlike traditional Linux filesystems, btrfs filesystems will allocate storage on-demand from the underlying volume.

In the btrfs world, the word volume corresponds to a storage pool (ZFS) or a volume group (LVM).

  • devices - one or multiple underlying physical volumes.
  • volume - one large storage pool comprised of all space of the devices and can support different redundancy levels
  • subvolumes - these are what get mounted and you store files in.
  • snapshots - a read-only copy of a subvolume at a given point in time and/or read-write copy of a subvolume in time (aka clone).

Creating a Volume

To create a basic btrfs volume, you will need an extra empty disk. Perform the following steps:

root #  mkfs.btrfs /dev/sdxy
btrfs-progs v4.17.1 
See http://btrfs.wiki.kernel.org for more information.

Detected a SSD, turning off metadata duplication.  Mkfs with -m dup if you want to force metadata duplication.
Performing full device TRIM /dev/sdj (223.57GiB) ...
Label:              (null)
UUID:               d6bcba6e-8fd5-41fc-9bb4-79628c5c928c
Node size:          16384
Sector size:        4096
Filesystem size:    223.57GiB
Block group profiles:
  Data:             single            8.00MiB
  Metadata:         single            8.00MiB
  System:           single            4.00MiB
SSD detected:       yes
Incompat features:  extref, skinny-metadata
Number of devices:  1
Devices:
   ID        SIZE  PATH
    1   223.57GiB  /dev/sdxy

/dev/sdxy should be an unused disk. You may need to use the following command if this disk contains any pre-existing data on it:

root #  mkfs.btrfs -f /dev/sdxy

Now you can mount the created volume as you would mount any other linux filesystem.

root #  mkdir /mnt/btrfs-top-level
root #  mount /dev/sdxy /mnt/btrfs-top-level
root #  mount
...
/dev/sdxy on /mnt/btrfs-top-level type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
   Warning

It is recommended that nothing is stored directly on this top-level volume (ID 5) root directory.

Creating Subvolumes

   Note

Changing subvolume layouts is made simpler by not using the top-level subvolume (ID 5) as /

Btrfs has a concept of subvolumes. Subvolume is an independently mountable POSIX filetree (but not a block device). There are several basic schemas to layout subvolumes (including snapshots) as well as mixtures thereof. The one described here was influenced by this SLES docs.

Lets create children of the top level subvolume (ID 5). We will have:

  • @funtoo - that will be our Funtoo Linux root filesystem: /home
  • @home - that will serve as / that e.g. can be also shared with other OS
  • snapshots - here backup snapshots will be stored

(later we will also create a nested subvolume under @funtoo)

root #  cd /mnt/btrfs-top-level
root #  btrfs subvolume create @funtoo
root #  btrfs subvolume create @home
root #  btrfs subvolume create snapshots
root #  btrfs subvolume list /mnt/btrfs-top-level
ID 256 gen 322336 top level 5 path @funtoo
ID 257 gen 322338 top level 5 path @home
ID 258 gen 322275 top level 5 path snapshots
   Note

This layout allows creation of granular snapshots, so that e.g. your /home data doesn't get lost or overwritten during a roll back of /.

Now lets reproduce steps from Install/Download and Extract Stage3 and populate @funtoo subvolume with Funtoo Linux Stage3

root #  cd @funtoo
root #  wget https://build.funtoo.org/next/x86-64bit/generic_64/stage3-latest.tar.xz
root #  tar --numeric-owner --xattrs --xattrs-include='*' -xpf stage3-latest.tar.xz

The default Subvolume

   Note

Changing the default subvolume with btrfs subvolume default will make the top level of the filesystem accessible only when subvol or subvolid mount options are specified

When we mount a btrfs block device without specifying a subvolume the default one is used. In order to check which subvolume is currently the default one run

root #  btrfs subvolume get-default /mnt/btrfs-top-level
ID 5 (FS_TREE)


For the convenience lets make our @funtoo subvolume as the default one. It's good to doublecheck the subvolume ID first. Let's use btrfs subvolume show command this time

root #  btrfs subvolume show /mnt/btrfs-top-level/@funtoo
...
	Subvolume ID: 		256

Now we can make this subvolume as a default one

root #  btrfs subvolume set-default 256 /mnt/btrfs-top-level
root #  btrfs subvolume get-default /mnt/btrfs-top-level

ID 256 gen 322336 top level 5 path @funtoo

At this point we can stop working on the top level subvolume (ID 5) and mount directly our @funtoo subvolume instead.

root #  cd /mnt
root #  umount /mnt/btrfs-top-level
root #  mkdir /mnt/funtoo
root #  mount /dev/sdxy /mnt/funtoo
root #  ls -la /mnt/funtoo
root #  cd /mnt/funtoo

Nested Subvolumes

todo



/etc/fstab

todo

To automatically mount this volume after reboot you need to add a simple fstab entry:

/dev/sdxy	/data	btrfs	defaults	0 0

You should now be at the point where you can begin to use btrfs for a variety of tasks. While there is a lot more to btrfs than what is covered in this short introduction, you should now have a good understanding of the fundamental concepts on which btrfs is based.