1 Btrfs:Balancing
2 ===============
3 :author: Aaron Ball
4 :email: nullspoon@iohq.net
5
6 == {doctitle}
7
8 I've been using https://btrfs.wiki.kernel.org[Btrfs] on all of my systems for a
9 couple of years now. Thus far, it's be surprisingly stable. In those two years
10 I only had link:Btrfs:RAID_5_Rsync_Freeze[one real issue]. However, today I ran into
11 a new problem. Now that I know what the issue is, it's hardly a problem, but
12 hey, semantics.
13
14 For my setup at home, I have a Linux server running all the time which hosts my
15 backups. My backups are copied via rsync. For security, my home directories on
16 all systems are encrypted block devices using
17 https://code.google.com/p/cryptsetup/wiki/DMCrypt[dm-crypt] with a
18 https://code.google.com/p/cryptsetup/[LUKS header]. To force myself to clean up
19 my files occasionally, I only give myself some 5 gigs of leeway. If I manage to
20 remove for example 10 gigs of files, I reduce the size of the filesystem and
21 block device container so I still only have about 2-5 gigs free (depends on
22 what I'm doing hobby-wise at the time). This is where my problem with Btrfs
23 comes in.
24
25
26 [[the-really-excitingboring-details]]
27 == The Really (Exciting|Boring) Details
28
29 This section might be super boring for some or most folks because it talks
30 about the innards of Btrfs. If you aren't interested, make like a Tatooine
31 speeder and move along... move along.
32
33 As more storage is needed for the filesystem, chunks of raw storage are
34 consumed by default 1 gigabyte at a time. As the
35 https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Data_usage_and_allocation[kernel.org
36 page] describes, these chunks are used for file data and/or metadata storage.
37 As more files are written to the filesystem, more metadata chunks are required
38 to describe the additional files (data to metadata ratios can be specified at
39 filesystem creation). By default, a metadata chunk cannot be used for data and
40 a data chunk cannot be used for metadata (kind of - there is a mixed mode which
41 is tremendously slow on filesystems larger than 1G). On a large storage device
42 this is fine, but if you are constantly deleting files like me, you may run
43 into the issue I ran into where the available space value is incorrect because
44 the various space checking commands check for available _data_ space, not
45 taking into account metadata. Because I delete so many files so often, there is
46 a lot of metadata storage that is allocated but is no longer used because the
47 files that the metadata were describing no longer exist, and thus the metadata
48 for those files do not either. Consequently, the metadata chunks are no longer
49 fully used (remember, they are allocated 1 G at a time). Due to the fact that
50 metadata and data chunks cannot be mixed by default, the underused metadata
51 chunks just consume storage from the overall available, reducing the amount of
52 available storage for data.
53
54 _*takes a deep breath*_
55
56
57 [[the-solution]]
58 == The Solution
59
60 The solution to this issue is called a rebalance (or balance as the btrfs
61 subcommand is called). What it will do is rewrite all of the data on the given
62 block device, sending it through the allocator algorithm before being rewritten
63 to the storage. This will cause the datas' metadata to be reallocated and
64 rewritten. What results is your metadata being "restacked", potentially causing
65 you to end up with completely empty 1G metadata chunks, thus freeing that
66 storage space for data. This isn't a complete analogy, but you can think of
67 this a [very] little like a defragment and cleanup process for metadata. Here's
68 the command.
69
70 ----
71 btrfs balance start /path/to/mount
72 ----
73
74 If you're interested in metrics, run
75
76 ----
77 btrfs filesystem df /path/to/mount
78 ----
79
80 before and after you run the balance and compare your metadata values.
81
82 Category:Btrfs
83 Category:Linux
84 Category:Filesystems
85
86
87 // vim: set syntax=asciidoc:
|
