summaryrefslogtreecommitdiffstats
path: root/upstream/opensuse-tumbleweed/man8/btrfs-balance.8
diff options
context:
space:
mode:
authorDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-15 19:43:11 +0000
committerDaniel Baumann <daniel.baumann@progress-linux.org>2024-04-15 19:43:11 +0000
commitfc22b3d6507c6745911b9dfcc68f1e665ae13dbc (patch)
treece1e3bce06471410239a6f41282e328770aa404a /upstream/opensuse-tumbleweed/man8/btrfs-balance.8
parentInitial commit. (diff)
downloadmanpages-l10n-fc22b3d6507c6745911b9dfcc68f1e665ae13dbc.tar.xz
manpages-l10n-fc22b3d6507c6745911b9dfcc68f1e665ae13dbc.zip
Adding upstream version 4.22.0.upstream/4.22.0
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'upstream/opensuse-tumbleweed/man8/btrfs-balance.8')
-rw-r--r--upstream/opensuse-tumbleweed/man8/btrfs-balance.8584
1 files changed, 584 insertions, 0 deletions
diff --git a/upstream/opensuse-tumbleweed/man8/btrfs-balance.8 b/upstream/opensuse-tumbleweed/man8/btrfs-balance.8
new file mode 100644
index 00000000..c30684c6
--- /dev/null
+++ b/upstream/opensuse-tumbleweed/man8/btrfs-balance.8
@@ -0,0 +1,584 @@
+.\" Man page generated from reStructuredText.
+.
+.
+.nr rst2man-indent-level 0
+.
+.de1 rstReportMargin
+\\$1 \\n[an-margin]
+level \\n[rst2man-indent-level]
+level margin: \\n[rst2man-indent\\n[rst2man-indent-level]]
+-
+\\n[rst2man-indent0]
+\\n[rst2man-indent1]
+\\n[rst2man-indent2]
+..
+.de1 INDENT
+.\" .rstReportMargin pre:
+. RS \\$1
+. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin]
+. nr rst2man-indent-level +1
+.\" .rstReportMargin post:
+..
+.de UNINDENT
+. RE
+.\" indent \\n[an-margin]
+.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.nr rst2man-indent-level -1
+.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]]
+.in \\n[rst2man-indent\\n[rst2man-indent-level]]u
+..
+.TH "BTRFS-BALANCE" "8" "Feb 14, 2024" "6.7.1" "BTRFS"
+.SH NAME
+btrfs-balance \- balance block groups on a btrfs filesystem
+.SH SYNOPSIS
+.sp
+\fBbtrfs balance\fP <subcommand> <args>
+.SH DESCRIPTION
+.sp
+The primary purpose of the balance feature is to spread block groups across
+all devices so they match constraints defined by the respective profiles. See
+\fI\%mkfs.btrfs(8)\fP section \fI\%PROFILES\fP
+for more details.
+The scope of the balancing process can be further tuned by use of filters that
+can select the block groups to process. Balance works only on a mounted
+filesystem. Extent sharing is preserved and reflinks are not broken.
+Files are not defragmented nor recompressed, file extents are preserved
+but the physical location on devices will change.
+.sp
+The balance operation is cancellable by the user. The on\-disk state of the
+filesystem is always consistent so an unexpected interruption (e.g. system crash,
+reboot) does not corrupt the filesystem. The progress of the balance operation
+is temporarily stored as an internal state and will be resumed upon mount,
+unless the mount option \fIskip_balance\fP is specified.
+.sp
+\fBWARNING:\fP
+.INDENT 0.0
+.INDENT 3.5
+Running balance without filters will take a lot of time as it basically move
+data/metadata from the whole filesystem and needs to update all block
+pointers.
+.UNINDENT
+.UNINDENT
+.sp
+The filters can be used to perform following actions:
+.INDENT 0.0
+.IP \(bu 2
+convert block group profiles (filter \fIconvert\fP)
+.IP \(bu 2
+make block group usage more compact (filter \fIusage\fP)
+.IP \(bu 2
+perform actions only on a given device (filters \fIdevid\fP, \fIdrange\fP)
+.UNINDENT
+.sp
+The filters can be applied to a combination of block group types (data,
+metadata, system). Note that changing only the \fIsystem\fP type needs the force
+option. Otherwise \fIsystem\fP gets automatically converted whenever \fImetadata\fP
+profile is converted.
+.sp
+When metadata redundancy is reduced (e.g. from RAID1 to single) the force option
+is also required and it is noted in system log.
+.sp
+\fBNOTE:\fP
+.INDENT 0.0
+.INDENT 3.5
+The balance operation needs enough work space, i.e. space that is completely
+unused in the filesystem, otherwise this may lead to ENOSPC reports. See
+the section \fIENOSPC\fP for more details.
+.UNINDENT
+.UNINDENT
+.SH COMPATIBILITY
+.sp
+\fBNOTE:\fP
+.INDENT 0.0
+.INDENT 3.5
+The balance subcommand also exists under the \fBbtrfs filesystem\fP namespace.
+This still works for backward compatibility but is deprecated and should not
+be used any more.
+.UNINDENT
+.UNINDENT
+.sp
+\fBNOTE:\fP
+.INDENT 0.0
+.INDENT 3.5
+A short syntax \fBbtrfs balance <path>\fP works due to backward compatibility
+but is deprecated and should not be used any more. Use \fBbtrfs balance start\fP
+command instead.
+.UNINDENT
+.UNINDENT
+.SH PERFORMANCE IMPLICATIONS
+.sp
+Balancing operations are very IO intensive and can also be quite CPU intensive,
+impacting other ongoing filesystem operations. Typically large amounts of data
+are copied from one location to another, with corresponding metadata updates.
+.sp
+Depending upon the block group layout, it can also be seek heavy. Performance
+on rotational devices is noticeably worse compared to SSDs or fast arrays.
+.SH SUBCOMMAND
+.INDENT 0.0
+.TP
+.B cancel <path>
+cancels a running or paused balance, the command will block and wait until the
+current block group being processed completes
+.sp
+Since kernel 5.7 the response time of the cancellation is significantly
+improved, on older kernels it might take a long time until currently
+processed chunk is completely finished.
+.TP
+.B pause <path>
+pause running balance operation, this will store the state of the balance
+progress and used filters to the filesystem
+.TP
+.B resume <path>
+resume interrupted balance, the balance status must be stored on the filesystem
+from previous run, e.g. after it was paused or forcibly interrupted and mounted
+again with \fIskip_balance\fP
+.TP
+.B start [options] <path>
+start the balance operation according to the specified filters, without any filters
+the data and metadata from the whole filesystem are moved. The process runs in
+the foreground.
+.sp
+\fBNOTE:\fP
+.INDENT 7.0
+.INDENT 3.5
+The balance command without filters will basically move everything in the
+filesystem to a new physical location on devices (i.e. it does not affect the
+logical properties of file extents like offsets within files and extent
+sharing). The run time is potentially very long, depending on the filesystem
+size. To prevent starting a full balance by accident, the user is warned and
+has a few seconds to cancel the operation before it starts. The warning and
+delay can be skipped with \fI\-\-full\-balance\fP option.
+.UNINDENT
+.UNINDENT
+.sp
+Please note that the filters must be written together with the \fI\-d\fP, \fI\-m\fP and
+\fI\-s\fP options, because they\(aqre optional and bare \fI\-d\fP and \fI\-m\fP also work and
+mean no filters.
+.sp
+\fBNOTE:\fP
+.INDENT 7.0
+.INDENT 3.5
+When the target profile for conversion filter is \fIraid5\fP or \fIraid6\fP,
+there\(aqs a safety timeout of 10 seconds to warn users about the status of the feature
+.UNINDENT
+.UNINDENT
+.sp
+\fBOptions\fP
+.INDENT 7.0
+.TP
+.B \-d[<filters>]
+act on data block groups, see section \fI\%FILTERS\fP for details about \fIfilters\fP
+.TP
+.B \-m[<filters>]
+act on metadata chunks, see \fI\%FILTERS\fP for details about \fIfilters\fP
+.TP
+.B \-s[<filters>]
+act on system chunks (requires \fI\-f\fP), see \fI\%FILTERS\fP for details about \fIfilters\fP\&.
+.UNINDENT
+.INDENT 7.0
+.TP
+.B \-f
+force a reduction of metadata integrity, e.g. when going from \fIraid1\fP to
+\fIsingle\fP, or skip safety timeout when the target conversion profile is \fIraid5\fP
+or \fIraid6\fP
+.UNINDENT
+.INDENT 7.0
+.TP
+.B \-\-background|\-\-bg
+run the balance operation asynchronously in the background, uses \fBfork(2)\fP to
+start the process that calls the kernel ioctl
+.UNINDENT
+.INDENT 7.0
+.TP
+.B \-\-enqueue
+wait if there\(aqs another exclusive operation running, otherwise continue
+.TP
+.B \-v
+(deprecated) alias for global \(aq\-v\(aq option
+.UNINDENT
+.TP
+.B status [\-v] <path>
+Show status of running or paused balance.
+.sp
+\fBOptions\fP
+.INDENT 7.0
+.TP
+.B \-v
+(deprecated) alias for global \fI\-v\fP option
+.UNINDENT
+.UNINDENT
+.SH FILTERS
+.sp
+From kernel 3.3 onwards, BTRFS balance can limit its action to a subset of the
+whole filesystem, and can be used to change the replication configuration (e.g.
+convert data from \fBsingle\fP to \fBRAID1\fP).
+.sp
+Balance can be limited to a block group profile with the following options:
+.INDENT 0.0
+.IP \(bu 2
+\fB\-d\fP for data block groups
+.IP \(bu 2
+\fB\-m\fP for metadata block groups (also implicitly applies to \fI\-s\fP)
+.IP \(bu 2
+\fB\-s\fP for system block groups
+.UNINDENT
+.sp
+The options have an optional parameter which means that the parameter must start
+right after the option without a space (this is mandatory getopt syntax), like
+\fB\-dusage=10\fP\&. Options for all block group types can be specified in one command.
+.sp
+A filter has the following structure: \fBfilter[=params][,filter=...]\fP
+.sp
+To combine multiple filters use \fB,\fP, without spaces. Example: \fB\-dconvert=raid1,soft\fP
+.sp
+BTRFS can have different profiles on a single device or the same profile on
+multiple device.
+.sp
+The main reason why you want to have different profiles for data and metadata
+is to provide additional protection of the filesystem\(aqs metadata when devices fail,
+since a single sector of unrecoverable metadata will break the filesystem,
+while a single sector of lost data can be trivially recovered by deleting the broken file.
+.sp
+Before changing profiles, make sure there is enough unallocated space on
+existing drives to create new metadata block groups (for filesystems
+over 50GiB, this is \fB1GB * (number_of_devices + 2))\fP\&.
+.sp
+Default profiles on BTRFS are:
+.INDENT 0.0
+.IP \(bu 2
+data: \fBsingle\fP
+.IP \(bu 2
+.INDENT 2.0
+.TP
+.B metadata:
+.INDENT 7.0
+.IP \(bu 2
+single devices: \fBdup\fP
+.IP \(bu 2
+multiple devices: \fBraid1\fP
+.UNINDENT
+.UNINDENT
+.UNINDENT
+.sp
+The available filter types are:
+.SS Filter types
+.INDENT 0.0
+.TP
+.B profiles=<profiles>
+Balances only block groups with the given profiles. Parameters
+are a list of profile names separated by \fB|\fP (pipe).
+.TP
+.B usage=<percent>, usage=<range>
+Balances only block groups with usage under the given percentage. The
+value of 0 is allowed and will clean up completely unused block groups, this
+should not require any new work space allocated. You may want to use \fIusage=0\fP
+in case balance is returning ENOSPC and your filesystem is not too full.
+.sp
+The argument may be a single value or a range. The single value \fBN\fP means \fIat
+most N percent used\fP, equivalent to \fB\&..N\fP range syntax. Kernels prior to 4.4
+accept only the single value format.
+The minimum range boundary is inclusive, maximum is exclusive.
+.TP
+.B devid=<id>
+Balances only block groups which have at least one chunk on the given
+device. To list devices with ids use \fBbtrfs filesystem show\fP\&.
+.TP
+.B drange=<range>
+Balance only block groups which overlap with the given byte range on any
+device. Use in conjunction with \fBdevid\fP to filter on a specific device. The
+parameter is a range specified as \fBstart..end\fP\&.
+.TP
+.B vrange=<range>
+Balance only block groups which overlap with the given byte range in the
+filesystem\(aqs internal virtual address space. This is the address space that
+most reports from btrfs in the kernel log use. The parameter is a range
+specified as \fBstart..end\fP\&.
+.TP
+.B convert=<profile>
+Convert each selected block group to the given profile name identified by
+parameters.
+.sp
+\fBNOTE:\fP
+.INDENT 7.0
+.INDENT 3.5
+Starting with kernel 4.5, the \fBdata\fP chunks can be converted to/from the
+\fBDUP\fP profile on a single device.
+.UNINDENT
+.UNINDENT
+.sp
+\fBNOTE:\fP
+.INDENT 7.0
+.INDENT 3.5
+Starting with kernel 4.6, all profiles can be converted to/from \fBDUP\fP on
+multi\-device filesystems.
+.UNINDENT
+.UNINDENT
+.TP
+.B limit=<number>, limit=<range>
+Process only given number of chunks, after all filters are applied. This can be
+used to specifically target a chunk in connection with other filters (\fBdrange\fP,
+\fBvrange\fP) or just simply limit the amount of work done by a single balance run.
+.sp
+The argument may be a single value or a range. The single value \fBN\fP means \fIat
+most N chunks\fP, equivalent to \fB\&..N\fP range syntax. Kernels prior to 4.4 accept
+only the single value format. The range minimum and maximum are inclusive.
+.TP
+.B stripes=<range>
+Balance only block groups which have the given number of stripes. The parameter
+is a range specified as \fBstart..end\fP\&. Makes sense for block group profiles that
+utilize striping, i.e. RAID0/10/5/6. The range minimum and maximum are
+inclusive.
+.TP
+.B soft
+Takes no parameters. Only has meaning when converting between profiles, or
+When doing convert from one profile to another and soft mode is on,
+chunks that already have the target profile are left untouched.
+This is useful e.g. when half of the filesystem was converted earlier but got
+cancelled.
+.sp
+The soft mode switch is (like every other filter) per\-type.
+For example, this means that we can convert metadata chunks the \(dqhard\(dq way
+while converting data chunks selectively with soft switch.
+.UNINDENT
+.sp
+Profile names, used in \fBprofiles\fP and \fBconvert\fP are one of:
+.INDENT 0.0
+.IP \(bu 2
+\fBraid0\fP
+.IP \(bu 2
+\fBraid1\fP
+.IP \(bu 2
+\fBraid1c3\fP
+.IP \(bu 2
+\fBraid1c4\fP
+.IP \(bu 2
+\fBraid10\fP
+.IP \(bu 2
+\fBraid5\fP
+.IP \(bu 2
+\fBraid6\fP
+.IP \(bu 2
+\fBdup\fP
+.IP \(bu 2
+\fBsingle\fP
+.UNINDENT
+.sp
+The mixed data/metadata profiles can be converted in the same way, but conversion
+between mixed and non\-mixed is not implemented. For the constraints of the
+profiles please refer to \fI\%mkfs.btrfs(8)\fP section
+\fI\%PROFILES\fP\&.
+.SH ENOSPC
+.sp
+The way balance operates, it usually needs to temporarily create a new block
+group and move the old data there, before the old block group can be removed.
+For that it needs the work space, otherwise it fails for ENOSPC reasons.
+This is not the same ENOSPC as if the free space is exhausted. This refers to
+the space on the level of block groups, which are bigger parts of the filesystem
+that contain many file extents.
+.sp
+The free work space can be calculated from the output of the \fBbtrfs filesystem show\fP
+command:
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+Label: \(aqBTRFS\(aq uuid: 8a9d72cd\-ead3\-469d\-b371\-9c7203276265
+ Total devices 2 FS bytes used 77.03GiB
+ devid 1 size 53.90GiB used 51.90GiB path /dev/sdc2
+ devid 2 size 53.90GiB used 51.90GiB path /dev/sde1
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+\fIsize\fP \- \fIused\fP = \fIfree work space\fP
+.sp
+\fI53.90GiB\fP \- \fI51.90GiB\fP = \fI2.00GiB\fP
+.sp
+An example of a filter that does not require workspace is \fIusage=0\fP\&. This will
+scan through all unused block groups of a given type and will reclaim the
+space. After that it might be possible to run other filters.
+.sp
+\fBCONVERSIONS ON MULTIPLE DEVICES\fP
+.sp
+Conversion to profiles based on striping (RAID0, RAID5/6) require the work
+space on each device. An interrupted balance may leave partially filled block
+groups that consume the work space.
+.SH EXAMPLES
+.sp
+A more comprehensive example when going from one to multiple devices, and back,
+can be found in section \fITYPICAL USECASES\fP of \fI\%btrfs\-device(8)\fP\&.
+.SS MAKING BLOCK GROUP LAYOUT MORE COMPACT
+.sp
+The layout of block groups is not normally visible; most tools report only
+summarized numbers of free or used space, but there are still some hints
+provided.
+.sp
+Let\(aqs use the following real life example and start with the output:
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+$ btrfs filesystem df /path
+Data, single: total=75.81GiB, used=64.44GiB
+System, RAID1: total=32.00MiB, used=20.00KiB
+Metadata, RAID1: total=15.87GiB, used=8.84GiB
+GlobalReserve, single: total=512.00MiB, used=0.00B
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+Roughly calculating for data, \fI75G \- 64G = 11G\fP, the used/total ratio is
+about \fI85%\fP\&. How can we can interpret that:
+.INDENT 0.0
+.IP \(bu 2
+chunks are filled by 85% on average, i.e. the \fIusage\fP filter with anything
+smaller than 85 will likely not affect anything
+.IP \(bu 2
+in a more realistic scenario, the space is distributed unevenly, we can
+assume there are completely used chunks and the remaining are partially filled
+.UNINDENT
+.sp
+Compacting the layout could be used on both. In the former case it would spread
+data of a given chunk to the others and removing it. Here we can estimate that
+roughly 850 MiB of data have to be moved (85% of a 1 GiB chunk).
+.sp
+In the latter case, targeting the partially used chunks will have to move less
+data and thus will be faster. A typical filter command would look like:
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+# btrfs balance start \-dusage=50 /path
+Done, had to relocate 2 out of 97 chunks
+
+$ btrfs filesystem df /path
+Data, single: total=74.03GiB, used=64.43GiB
+System, RAID1: total=32.00MiB, used=20.00KiB
+Metadata, RAID1: total=15.87GiB, used=8.84GiB
+GlobalReserve, single: total=512.00MiB, used=0.00B
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+As you can see, the \fItotal\fP amount of data is decreased by just 1 GiB, which is
+an expected result. Let\(aqs see what will happen when we increase the estimated
+usage filter.
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+# btrfs balance start \-dusage=85 /path
+Done, had to relocate 13 out of 95 chunks
+
+$ btrfs filesystem df /path
+Data, single: total=68.03GiB, used=64.43GiB
+System, RAID1: total=32.00MiB, used=20.00KiB
+Metadata, RAID1: total=15.87GiB, used=8.85GiB
+GlobalReserve, single: total=512.00MiB, used=0.00B
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+Now the used/total ratio is about 94% and we moved about \fI74G \- 68G = 6G\fP of
+data to the remaining block groups, i.e. the 6GiB are now free of filesystem
+structures, and can be reused for new data or metadata block groups.
+.sp
+We can do a similar exercise with the metadata block groups, but this should
+not typically be necessary, unless the used/total ratio is really off. Here
+the ratio is roughly 50% but the difference as an absolute number is \(dqa few
+gigabytes\(dq, which can be considered normal for a workload with snapshots or
+reflinks updated frequently.
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+# btrfs balance start \-musage=50 /path
+Done, had to relocate 4 out of 89 chunks
+
+$ btrfs filesystem df /path
+Data, single: total=68.03GiB, used=64.43GiB
+System, RAID1: total=32.00MiB, used=20.00KiB
+Metadata, RAID1: total=14.87GiB, used=8.85GiB
+GlobalReserve, single: total=512.00MiB, used=0.00B
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+Just 1 GiB decrease, which possibly means there are block groups with good
+utilization. Making the metadata layout more compact would in turn require
+updating more metadata structures, i.e. lots of IO. As running out of metadata
+space is a more severe problem, it\(aqs not necessary to keep the utilization
+ratio too high. For the purpose of this example, let\(aqs see the effects of
+further compaction:
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+# btrfs balance start \-musage=70 /path
+Done, had to relocate 13 out of 88 chunks
+
+$ btrfs filesystem df .
+Data, single: total=68.03GiB, used=64.43GiB
+System, RAID1: total=32.00MiB, used=20.00KiB
+Metadata, RAID1: total=11.97GiB, used=8.83GiB
+GlobalReserve, single: total=512.00MiB, used=0.00B
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.SS GETTING RID OF COMPLETELY UNUSED BLOCK GROUPS
+.sp
+Normally the balance operation needs a work space, to temporarily move the
+data before the old block groups gets removed. If there\(aqs no work space, it
+ends with \fIno space left\fP\&.
+.sp
+There\(aqs a special case when the block groups are completely unused, possibly
+left after removing lots of files or deleting snapshots. Removing empty block
+groups is automatic since 3.18. The same can be achieved manually with a
+notable exception that this operation does not require the work space. Thus it
+can be used to reclaim unused block groups to make it available.
+.INDENT 0.0
+.INDENT 3.5
+.sp
+.nf
+.ft C
+# btrfs balance start \-dusage=0 /path
+.ft P
+.fi
+.UNINDENT
+.UNINDENT
+.sp
+This should lead to decrease in the \fItotal\fP numbers in the \fBbtrfs filesystem df\fP output.
+.SH EXIT STATUS
+.sp
+Unless indicated otherwise below, all \fBbtrfs balance\fP subcommands
+return a zero exit status if they succeed, and non zero in case of
+failure.
+.sp
+The \fBpause\fP, \fBcancel\fP, and \fBresume\fP subcommands exit with a status of
+\fB2\fP if they fail because a balance operation was not running.
+.sp
+The \fBstatus\fP subcommand exits with a status of \fB0\fP if a balance
+operation is not running, \fB1\fP if the command\-line usage is incorrect
+or a balance operation is still running, and \fB2\fP on other errors.
+.SH AVAILABILITY
+.sp
+\fBbtrfs\fP is part of btrfs\-progs. Please refer to the documentation at
+\fI\%https://btrfs.readthedocs.io\fP\&.
+.SH SEE ALSO
+.sp
+\fI\%mkfs.btrfs(8)\fP,
+\fI\%btrfs\-device(8)\fP
+.\" Generated by docutils manpage writer.
+.