diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-15 19:43:11 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-15 19:43:11 +0000 |
commit | fc22b3d6507c6745911b9dfcc68f1e665ae13dbc (patch) | |
tree | ce1e3bce06471410239a6f41282e328770aa404a /upstream/opensuse-tumbleweed/man8/btrfs-balance.8 | |
parent | Initial commit. (diff) | |
download | manpages-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.8 | 584 |
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. +. |