|
|
| Line 1: |
Line 1: |
| − | =mkfs.btrfs(8) manual page=
| |
| | {{GeneratedManpage | | {{GeneratedManpage |
| | |name=mkfs.btrfs}} | | |name=mkfs.btrfs}} |
| − |
| |
| − | ==NAME==
| |
| − | mkfs.btrfs - create a btrfs filesystem
| |
| − |
| |
| − | ==SYNOPSIS==
| |
| − |
| |
| − | <p><b>mkfs.btrfs</b> [options] <em><device></em> [<em><device></em>…]</p>
| |
| − | ==DESCRIPTION==
| |
| − |
| |
| − | <p><b>mkfs.btrfs</b> is used to create the btrfs filesystem on a single or multiple
| |
| − | devices. <em><device></em> is typically a block device but can be a file-backed image
| |
| − | as well. Multiple devices are grouped by UUID of the filesystem.</p>
| |
| − | <p>Before mounting such filesystem, the kernel module must know all the devices
| |
| − | either via preceding execution of <b>btrfs device scan</b> or using the <b>device</b>
| |
| − | mount option. See section <b>MULTIPLE DEVICES</b> for more details.</p>
| |
| − | <p>The default block group profiles for data and metadata depend on number of
| |
| − | devices and possibly other factors. It’s recommended to use specific profiles
| |
| − | but the defaults should be OK and allowing future conversions to other profiles.
| |
| − | Please see options <em>-d</em> and <em>-m</em> for further detals and [[Manpage/btrfs-balance|btrfs-balance(8)]] for
| |
| − | the profile conversion post mkfs.</p>
| |
| − | ==OPTIONS==
| |
| − |
| |
| − | <dl>
| |
| − | <dt>
| |
| − | <b>-b|--byte-count <em><size></em></b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Specify the size of the filesystem. If this option is not used, then
| |
| − | mkfs.btrfs uses the entire device space for the filesystem.
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>--csum <em><type></em></b>
| |
| − | <dt>
| |
| − | <b>--checksum <em><type></em></b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Specify the checksum algorithm. Default is <em>crc32c</em>. Valid values are <em>crc32c</em>,
| |
| − | <em>xxhash</em>, <em>sha256</em> or <em>blake2</em>. To mount such filesystem kernel must support the
| |
| − | checksums as well. See <em>CHECKSUM ALGORITHMS</em> in [[Manpage/btrfs|btrfs(5)]].
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-d|--data <em><profile></em></b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Specify the profile for the data block groups. Valid values are <em>raid0</em>,
| |
| − | <em>raid1</em>, <em>raid1c3</em>, <em>raid1c4</em>, <em>raid5</em>, <em>raid6</em>, <em>raid10</em> or <em>single</em> or <em>dup</em>
| |
| − | (case does not matter).
| |
| − | </p>
| |
| − | <p>See <em>DUP PROFILES ON A SINGLE DEVICE</em> for more details.</p>
| |
| − | <p>On multiple devices, the default was <em>raid0</em> until version 5.7, while it is
| |
| − | <em>single</em> since version 5.8. You can still select raid0 manually, but it was not
| |
| − | suitable as default.</p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-m|--metadata <em><profile></em></b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Specify the profile for the metadata block groups.
| |
| − | Valid values are <em>raid0</em>, <em>raid1</em>, <em>raid1c3</em>, <em>raid1c4</em>, <em>raid5</em>, <em>raid6</em>,
| |
| − | <em>raid10</em>, <em>single</em> or <em>dup</em> (case does not matter).
| |
| − | </p>
| |
| − | <p>Default on a single device filesystem is <em>DUP</em> and is recommended for metadata
| |
| − | in general. The duplication might not be necessary in some use cases and it’s
| |
| − | up to the user to changed that at mkfs time or later. This depends on hardware
| |
| − | that could potentially deduplicate the blocks again but this cannot be detected
| |
| − | at mkfs time.</p>
| |
| − | <blockquote><b>Note:</b>
| |
| − |
| |
| − | <p>Up to version 5.14 there was a detection of a SSD device (more precisely
| |
| − | if it’s a rotational device, determined by the contents of file
| |
| − | <tt>/sys/block/DEV/queue/rotational</tt>) that used to select <em>single</em>. This has
| |
| − | changed in version 5.15 to be always <em>dup</em>.</p>
| |
| − | <p>Note that the rotational status can be arbitrarily set by the underlying block
| |
| − | device driver and may not reflect the true status (network block device, memory-backed
| |
| − | SCSI devices, real block device behind some additonal device mapper layer,
| |
| − | etc). It’s recommended to always set the options <em>--data/--metadata</em> to avoid
| |
| − | confusion and unexpected results.</p>
| |
| − | <p>See <em>DUP PROFILES ON A SINGLE DEVICE</em> for more details.</p>
| |
| − | </blockquote>
| |
| − | <p>On multiple devices the default is <em>raid1</em>.</p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-M|--mixed</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Normally the data and metadata block groups are isolated. The <em>mixed</em> mode
| |
| − | will remove the isolation and store both types in the same block group type.
| |
| − | This helps to utilize the free space regardless of the purpose and is suitable
| |
| − | for small devices. The separate allocation of block groups leads to a situation
| |
| − | where the space is reserved for the other block group type, is not available for
| |
| − | allocation and can lead to ENOSPC state.
| |
| − | </p>
| |
| − | <p>The recommended size for the mixed mode is for filesystems less than 1GiB. The
| |
| − | soft recommendation is to use it for filesystems smaller than 5GiB. The mixed
| |
| − | mode may lead to degraded performance on larger filesystems, but is otherwise
| |
| − | usable, even on multiple devices.</p>
| |
| − | <p>The <em>nodesize</em> and <em>sectorsize</em> must be equal, and the block group types must
| |
| − | match.</p>
| |
| − | <blockquote><b>Note:</b>
| |
| − | versions up to 4.2.x forced the mixed mode for devices smaller than 1GiB.
| |
| − | This has been removed in 4.3+ as it caused some usability issues.</blockquote>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-l|--leafsize <em><size></em></b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Alias for --nodesize. Deprecated.
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-n|--nodesize <em><size></em></b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Specify the nodesize, the tree block size in which btrfs stores metadata. The
| |
| − | default value is 16KiB (16384) or the page size, whichever is bigger. Must be a
| |
| − | multiple of the sectorsize and a power of 2, but not larger than 64KiB (65536).
| |
| − | Leafsize always equals nodesize and the options are aliases.
| |
| − | </p>
| |
| − | <p>Smaller node size increases fragmentation but leads to taller b-trees which in
| |
| − | turn leads to lower locking contention. Higher node sizes give better packing
| |
| − | and less fragmentation at the cost of more expensive memory operations while
| |
| − | updating the metadata blocks.</p>
| |
| − | <blockquote><b>Note:</b>
| |
| − | versions up to 3.11 set the nodesize to 4k.</blockquote>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-s|--sectorsize <em><size></em></b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Specify the sectorsize, the minimum data block allocation unit.
| |
| − | </p>
| |
| − | <p>The default value is the page size and is autodetected. If the sectorsize
| |
| − | differs from the page size, the created filesystem may not be mountable by the
| |
| − | running kernel. Therefore it is not recommended to use this option unless you
| |
| − | are going to mount it on a system with the appropriate page size.</p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-L|--label <em><string></em></b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Specify a label for the filesystem. The <em>string</em> should be less than 256
| |
| − | bytes and must not contain newline characters.
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-K|--nodiscard</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Do not perform whole device TRIM operation on devices that are capable of that.
| |
| − | This does not affect discard/trim operation when the filesystem is mounted.
| |
| − | Please see the mount option <em>discard</em> for that in [[Manpage/btrfs|btrfs(5)]].
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-r|--rootdir <em><rootdir></em></b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Populate the toplevel subvolume with files from <em>rootdir</em>. This does not
| |
| − | require root permissions to write the new files or to mount the filesystem.
| |
| − | </p>
| |
| − | <blockquote><b>Note:</b>
| |
| − | This option may enlarge the image or file to ensure it’s big enough to
| |
| − | contain the files from <em>rootdir</em>. Since version 4.14.1 the filesystem size is
| |
| − | not minimized. Please see option <em>--shrink</em> if you need that functionality.</blockquote>
| |
| − |
| |
| − | <dt>
| |
| − | <b>--shrink</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Shrink the filesystem to its minimal size, only works with <em>--rootdir</em> option.
| |
| − | </p>
| |
| − | <p>If the destination block device is a regular file, this option will also
| |
| − | truncate the file to the minimal size. Otherwise it will reduce the filesystem
| |
| − | available space. Extra space will not be usable unless the filesystem is
| |
| − | mounted and resized using <em>btrfs filesystem resize</em>.</p>
| |
| − | <blockquote><b>Note:</b>
| |
| − | prior to version 4.14.1, the shrinking was done automatically.</blockquote>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-O|--features <em><feature1></em>[,<em><feature2></em>…]</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | A list of filesystem features turned on at mkfs time. Not all features are
| |
| − | supported by old kernels. To disable a feature, prefix it with <em>^</em>.
| |
| − | </p>
| |
| − | <p>See section <b>FILESYSTEM FEATURES</b> for more details. To see all available
| |
| − | features that mkfs.btrfs supports run:</p>
| |
| − | <p><tt>mkfs.btrfs -O list-all</tt></p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-R|--runtime-features <em><feature1></em>[,<em><feature2></em>…]</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | A list of features that be can enabled at mkfs time, otherwise would have
| |
| − | to be turned on a mounted filesystem.
| |
| − | Although no runtime feature is enabled by default,
| |
| − | to disable a feature, prefix it with <em>^</em>.
| |
| − | </p>
| |
| − | <p>See section <b>RUNTIME FEATURES</b> for more details. To see all available
| |
| − | runtime features that mkfs.btrfs supports run:</p>
| |
| − | <p><tt>mkfs.btrfs -R list-all</tt></p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-f|--force</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Forcibly overwrite the block devices when an existing filesystem is detected.
| |
| − | By default, mkfs.btrfs will utilize <em>libblkid</em> to check for any known
| |
| − | filesystem on the devices. Alternatively you can use the <tt>wipefs</tt> utility
| |
| − | to clear the devices.
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-q|--quiet</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Print only error or warning messages. Options --features or --help are unaffected.
| |
| − | Resets any previous effects of <em>--verbose</em>.
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-U|--uuid <em><UUID></em></b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Create the filesystem with the given <em>UUID</em>. The UUID must not exist on any
| |
| − | filesystem currently present.
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-v|--verbose</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Increase verbosity level, default is 1.
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>-V|--version</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Print the <b>mkfs.btrfs</b> version and exit.
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>--help</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | Print help.
| |
| − | </p>
| |
| − |
| |
| − | </dl>
| |
| − | ==SIZE UNITS==
| |
| − |
| |
| − | <p>The default unit is <em>byte</em>. All size parameters accept suffixes in the 1024
| |
| − | base. The recognized suffixes are: <em>k</em>, <em>m</em>, <em>g</em>, <em>t</em>, <em>p</em>, <em>e</em>, both uppercase
| |
| − | and lowercase.</p>
| |
| − | ==MULTIPLE DEVICES==
| |
| − |
| |
| − | <p>Before mounting a multiple device filesystem, the kernel module must know the
| |
| − | association of the block devices that are attached to the filesystem UUID.</p>
| |
| − | <p>There is typically no action needed from the user. On a system that utilizes a
| |
| − | udev-like daemon, any new block device is automatically registered. The rules
| |
| − | call <b>btrfs device scan</b>.</p>
| |
| − | <p>The same command can be used to trigger the device scanning if the btrfs kernel
| |
| − | module is reloaded (naturally all previous information about the device
| |
| − | registration is lost).</p>
| |
| − | <p>Another possibility is to use the mount options <b>device</b> to specify the list of
| |
| − | devices to scan at the time of mount.</p>
| |
| − | <pre># mount -o device=/dev/sdb,device=/dev/sdc /dev/sda /mnt</pre>
| |
| − | <blockquote><b>Note:</b>
| |
| − | that this means only scanning, if the devices do not exist in the system,
| |
| − | mount will fail anyway. This can happen on systems without initramfs/initrd and
| |
| − | root partition created with RAID1/10/5/6 profiles. The mount action can happen
| |
| − | before all block devices are discovered. The waiting is usually done on the
| |
| − | initramfs/initrd systems.</blockquote>
| |
| − | <p>RAID5/6 has known problems and should not be used in production.</p>
| |
| − | ==FILESYSTEM FEATURES==
| |
| − |
| |
| − | <p>Features that can be enabled during creation time. See also [[Manpage/btrfs|btrfs(5)]] section
| |
| − | <em>FILESYSTEM FEATURES</em>.</p>
| |
| − | <dl>
| |
| − | <dt>
| |
| − | <b>mixed-bg</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | (kernel support since 2.6.37)
| |
| − | </p>
| |
| − | <p>mixed data and metadata block groups, also set by option <em>--mixed</em></p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>extref</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | (default since btrfs-progs 3.12, kernel support since 3.7)
| |
| − | </p>
| |
| − | <p>increased hardlink limit per file in a directory to 65536, older kernels
| |
| − | supported a varying number of hardlinks depending on the sum of all file name
| |
| − | sizes that can be stored into one metadata block</p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>raid56</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | (kernel support since 3.9)
| |
| − | </p>
| |
| − | <p>extended format for RAID5/6, also enabled if raid5 or raid6 block groups
| |
| − | are selected</p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>skinny-metadata</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | (default since btrfs-progs 3.18, kernel support since 3.10)
| |
| − | </p>
| |
| − | <p>reduced-size metadata for extent references, saves a few percent of metadata</p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>no-holes</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | (default since btrfs-progs 5.15, kernel support since 3.14)
| |
| − | </p>
| |
| − | <p>improved representation of file extents where holes are not explicitly
| |
| − | stored as an extent, saves a few percent of metadata if sparse files are used</p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>zoned</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | (kernel support since 5.12)
| |
| − | </p>
| |
| − | <p>zoned mode, data allocation and write friendly to zoned/SMR/ZBC/ZNS devices,
| |
| − | see <em>ZONED MODE</em> in [[Manpage/btrfs|btrfs(5)]], the mode is automatically selected when
| |
| − | a zoned device is detected</p>
| |
| − |
| |
| − | </dl>
| |
| − | ==RUNTIME FEATURES==
| |
| − |
| |
| − | <p>Features that are typically enabled on a mounted filesystem, eg. by a mount
| |
| − | option or by an ioctl. Some of them can be enabled early, at mkfs time. This
| |
| − | applies to features that need to be enabled once and then the status is
| |
| − | permanent, this does not replace mount options.</p>
| |
| − | <dl>
| |
| − | <dt>
| |
| − | <b>quota</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | (kernel support since 3.4)
| |
| − | </p>
| |
| − | <p>Enable quota support (qgroups). The qgroup accounting will be consistent,
| |
| − | can be used together with <em>--rootdir</em>. See also [[Manpage/btrfs-quota|btrfs-quota(8)]].</p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>free-space-tree</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | (default since btrfs-progs 5.15, kernel support since 4.5)
| |
| − | </p>
| |
| − | <p>Enable the free space tree (mount option space_cache=v2) for persisting the
| |
| − | free space cache.</p>
| |
| − |
| |
| − | </dl>
| |
| − | ==BLOCK GROUPS, CHUNKS, RAID==
| |
| − |
| |
| − | <p>The highlevel organizational units of a filesystem are block groups of three types:
| |
| − | data, metadata and system.</p>
| |
| − | <dl>
| |
| − | <dt>
| |
| − | <b>DATA</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | store data blocks and nothing else
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>METADATA</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | store internal metadata in b-trees, can store file data if they fit into the
| |
| − | inline limit
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>SYSTEM</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | store structures that describe the mapping between the physical devices and the
| |
| − | linear logical space representing the filesystem
| |
| − | </p>
| |
| − |
| |
| − | </dl>
| |
| − | <p>Other terms commonly used:</p>
| |
| − | <dl>
| |
| − | <dt>
| |
| − | <b>block group</b>
| |
| − | <dt>
| |
| − | <b>chunk</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | a logical range of space of a given profile, stores data, metadata or both;
| |
| − | sometimes the terms are used interchangeably
| |
| − | </p>
| |
| − | <p>A typical size of metadata block group is 256MiB (filesystem smaller than
| |
| − | 50GiB) and 1GiB (larger than 50GiB), for data it’s 1GiB. The system block group
| |
| − | size is a few megabytes.</p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>RAID</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | a block group profile type that utilizes RAID-like features on multiple
| |
| − | devices: striping, mirroring, parity
| |
| − | </p>
| |
| − |
| |
| − | <dt>
| |
| − | <b>profile</b>
| |
| − | <dd>
| |
| − | <p>
| |
| − | when used in connection with block groups refers to the allocation strategy
| |
| − | and constraints, see the section <em>PROFILES</em> for more details
| |
| − | </p>
| |
| − |
| |
| − | </dl>
| |
| − | ==PROFILES==
| |
| − |
| |
| − | <p>There are the following block group types available:</p>
| |
| − | <div>
| |
| − | <table rules="all"
| |
| − | width="60%"
| |
| − | frame="border"
| |
| − | cellspacing="0" cellpadding="4">
| |
| − | <tbody>
| |
| − | <tr>
| |
| − | <td rowspan="2" align="center" width="16%" valign="top"><p><strong>Profile</strong></p></td>
| |
| − | <td colspan="3" align="center" width="16%" valign="middle"><p><strong>Redundancy</strong></p></td>
| |
| − | <td rowspan="2" align="center" width="16%" valign="top"><p><strong>Space utilization</strong></p></td>
| |
| − | <td rowspan="2" align="center" width="16%" valign="top"><p><strong>Min/max devices</strong></p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="16%" valign="middle"><p><strong>Copies</strong></p></td>
| |
| − | <td align="center" width="16%" valign="middle"><p><strong>Parity</strong></p></td>
| |
| − | <td align="center" width="16%" valign="top"><p><strong>Striping</strong></p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="left" width="16%" valign="top"><p>single</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>1</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="right" width="16%" valign="top"><p>100%</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>1/any</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="left" width="16%" valign="top"><p>DUP</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>2 / 1 device</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="right" width="16%" valign="top"><p>50%</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>1/any <sup>(see note 1)</sup></p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="left" width="16%" valign="top"><p>RAID0</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>1 to N</p></td>
| |
| − | <td align="right" width="16%" valign="top"><p>100%</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>1/any <sup>(see note 5)</sup></p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="left" width="16%" valign="top"><p>RAID1</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>2</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="right" width="16%" valign="top"><p>50%</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>2/any</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="left" width="16%" valign="top"><p>RAID1C3</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>3</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="right" width="16%" valign="top"><p>33%</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>3/any</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="left" width="16%" valign="top"><p>RAID1C4</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>4</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="right" width="16%" valign="top"><p>25%</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>4/any</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="left" width="16%" valign="top"><p>RAID10</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>2</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p></p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>1 to N</p></td>
| |
| − | <td align="right" width="16%" valign="top"><p>50%</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>2/any <sup>(see note 5)</sup></p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="left" width="16%" valign="top"><p>RAID5</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>1</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>1</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>2 to N-1</p></td>
| |
| − | <td align="right" width="16%" valign="top"><p>(N-1)/N</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>2/any <sup>(see note 2)</sup></p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="left" width="16%" valign="top"><p>RAID6</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>1</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>2</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>3 to N-2</p></td>
| |
| − | <td align="right" width="16%" valign="top"><p>(N-2)/N</p></td>
| |
| − | <td align="center" width="16%" valign="top"><p>3/any <sup>(see note 3)</sup></p></td>
| |
| − | </tr>
| |
| − | </tbody>
| |
| − | </table>
| |
| − | </div>
| |
| − | <blockquote><b>Warning:</b>
| |
| − | It’s not recommended to create filesystems with RAID0/1/10/5/6
| |
| − | profiles on partitions from the same device. Neither redundancy nor
| |
| − | performance will be improved.</blockquote>
| |
| − | <p><em>Note 1:</em> DUP may exist on more than 1 device if it starts on a single device and
| |
| − | another one is added. Since version 4.5.1, <b>mkfs.btrfs</b> will let you create DUP
| |
| − | on multiple devices without restrictions.</p>
| |
| − | <p><em>Note 2:</em> It’s not recommended to use 2 devices with RAID5. In that case,
| |
| − | parity stripe will contain the same data as the data stripe, making RAID5
| |
| − | degraded to RAID1 with more overhead.</p>
| |
| − | <p><em>Note 3:</em> It’s also not recommended to use 3 devices with RAID6, unless you
| |
| − | want to get effectively 3 copies in a RAID1-like manner (but not exactly that).</p>
| |
| − | <p><em>Note 4:</em> Since kernel 5.5 it’s possible to use RAID1C3 as replacement for
| |
| − | RAID6, higher space cost but reliable.</p>
| |
| − | <p><em>Note 5:</em> Since kernel 5.15 it’s possible to use (mount, convert profiles)
| |
| − | RAID0 on one device and RAID10 on two devices.</p>
| |
| − | ===PROFILE LAYOUT===
| |
| − |
| |
| − | <p>For the following examples, assume devices numbered by 1, 2, 3 and 4, data or
| |
| − | metadata blocks A, B, C, D, with possible stripes eg. A1, A2 that would be
| |
| − | logically A, etc. For parity profiles PA and QA are parity and syndrom,
| |
| − | associated with the given stripe. The simple layouts single or DUP are left
| |
| − | out. Actual physical block placement on devices depends on current state of
| |
| − | the free/allocated space and may appear random. All devices are assumed to be
| |
| − | present at the time of the blocks would have been written.</p>
| |
| − | <p>RAID1</p>
| |
| − | <div>
| |
| − | <table rules="all"
| |
| − | width="50%"
| |
| − | frame="border"
| |
| − | cellspacing="0" cellpadding="4">
| |
| − | <thead>
| |
| − | <tr>
| |
| − | <th align="center" width="25%" valign="top"> device 1 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 2 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 3 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 4</th>
| |
| − | </tr>
| |
| − | </thead>
| |
| − | <tbody>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>A</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>B</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>C</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>C</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>D</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>A</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>B</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | </tr>
| |
| − | </tbody>
| |
| − | </table>
| |
| − | </div>
| |
| − | <p>RAID1C3</p>
| |
| − | <div>
| |
| − | <table rules="all"
| |
| − | width="50%"
| |
| − | frame="border"
| |
| − | cellspacing="0" cellpadding="4">
| |
| − | <thead>
| |
| − | <tr>
| |
| − | <th align="center" width="25%" valign="top"> device 1 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 2 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 3 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 4</th>
| |
| − | </tr>
| |
| − | </thead>
| |
| − | <tbody>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>A</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>A</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>B</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>B</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>C</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p></p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>A</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>C</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>D</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>C</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>B</p></td>
| |
| − | </tr>
| |
| − | </tbody>
| |
| − | </table>
| |
| − | </div>
| |
| − | <p>RAID0</p>
| |
| − | <div>
| |
| − | <table rules="all"
| |
| − | width="50%"
| |
| − | frame="border"
| |
| − | cellspacing="0" cellpadding="4">
| |
| − | <thead>
| |
| − | <tr>
| |
| − | <th align="center" width="25%" valign="top"> device 1 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 2 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 3 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 4</th>
| |
| − | </tr>
| |
| − | </thead>
| |
| − | <tbody>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>A2</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>C3</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>A3</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>C2</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>B1</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>A1</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D2</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>B3</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>C1</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D3</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>B4</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D1</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>D4</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>B2</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>C4</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>A4</p></td>
| |
| − | </tr>
| |
| − | </tbody>
| |
| − | </table>
| |
| − | </div>
| |
| − | <p>RAID5</p>
| |
| − | <div>
| |
| − | <table rules="all"
| |
| − | width="50%"
| |
| − | frame="border"
| |
| − | cellspacing="0" cellpadding="4">
| |
| − | <thead>
| |
| − | <tr>
| |
| − | <th align="center" width="25%" valign="top"> device 1 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 2 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 3 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 4</th>
| |
| − | </tr>
| |
| − | </thead>
| |
| − | <tbody>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>A2</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>C3</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>A3</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>C2</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>B1</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>A1</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D2</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>B3</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>C1</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D3</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>PB</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D1</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>PD</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>B2</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>PC</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>PA</p></td>
| |
| − | </tr>
| |
| − | </tbody>
| |
| − | </table>
| |
| − | </div>
| |
| − | <p>RAID6</p>
| |
| − | <div>
| |
| − | <table rules="all"
| |
| − | width="50%"
| |
| − | frame="border"
| |
| − | cellspacing="0" cellpadding="4">
| |
| − | <thead>
| |
| − | <tr>
| |
| − | <th align="center" width="25%" valign="top"> device 1 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 2 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 3 </th>
| |
| − | <th align="center" width="25%" valign="top"> device 4</th>
| |
| − | </tr>
| |
| − | </thead>
| |
| − | <tbody>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>A2</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>QC</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>QA</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>C2</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>B1</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>A1</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D2</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>QB</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>C1</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>QD</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>PB</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>D1</p></td>
| |
| − | </tr>
| |
| − | <tr>
| |
| − | <td align="center" width="25%" valign="top"><p>PD</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>B2</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>PC</p></td>
| |
| − | <td align="center" width="25%" valign="top"><p>PA</p></td>
| |
| − | </tr>
| |
| − | </tbody>
| |
| − | </table>
| |
| − | </div>
| |
| − | ==DUP PROFILES ON A SINGLE DEVICE==
| |
| − |
| |
| − | <p>The mkfs utility will let the user create a filesystem with profiles that write
| |
| − | the logical blocks to 2 physical locations. Whether there are really 2
| |
| − | physical copies highly depends on the underlying device type.</p>
| |
| − | <p>For example, a SSD drive can remap the blocks internally to a single copy—thus
| |
| − | deduplicating them. This negates the purpose of increased redundancy and just
| |
| − | wastes filesystem space without providing the expected level of redundancy.</p>
| |
| − | <p>The duplicated data/metadata may still be useful to statistically improve the
| |
| − | chances on a device that might perform some internal optimizations. The actual
| |
| − | details are not usually disclosed by vendors. For example we could expect that
| |
| − | not all blocks get deduplicated. This will provide a non-zero probability of
| |
| − | recovery compared to a zero chance if the single profile is used. The user
| |
| − | should make the tradeoff decision. The deduplication in SSDs is thought to be
| |
| − | widely available so the reason behind the mkfs default is to not give a false
| |
| − | sense of redundancy.</p>
| |
| − | <p>As another example, the widely used USB flash or SD cards use a translation
| |
| − | layer between the logical and physical view of the device. The data lifetime
| |
| − | may be affected by frequent plugging. The memory cells could get damaged,
| |
| − | hopefully not destroying both copies of particular data in case of DUP.</p>
| |
| − | <p>The wear levelling techniques can also lead to reduced redundancy, even if the
| |
| − | device does not do any deduplication. The controllers may put data written in
| |
| − | a short timespan into the same physical storage unit (cell, block etc). In case
| |
| − | this unit dies, both copies are lost. BTRFS does not add any artificial delay
| |
| − | between metadata writes.</p>
| |
| − | <p>The traditional rotational hard drives usually fail at the sector level.</p>
| |
| − | <p>In any case, a device that starts to misbehave and repairs from the DUP copy
| |
| − | should be replaced! <b>DUP is not backup</b>.</p>
| |
| − | ==KNOWN ISSUES==
| |
| − |
| |
| − | <p><b>SMALL FILESYSTEMS AND LARGE NODESIZE</b></p>
| |
| − | <p>The combination of small filesystem size and large nodesize is not recommended
| |
| − | in general and can lead to various ENOSPC-related issues during mount time or runtime.</p>
| |
| − | <p>Since mixed block group creation is optional, we allow small
| |
| − | filesystem instances with differing values for <em>sectorsize</em> and <em>nodesize</em>
| |
| − | to be created and could end up in the following situation:</p>
| |
| − | <pre># mkfs.btrfs -f -n 65536 /dev/loop0
| |
| − | btrfs-progs v3.19-rc2-405-g976307c
| |
| − | See http://btrfs.wiki.kernel.org for more information.</pre>
| |
| − | <pre>Performing full device TRIM (512.00MiB) ...
| |
| − | Label: (null)
| |
| − | UUID: 49fab72e-0c8b-466b-a3ca-d1bfe56475f0
| |
| − | Node size: 65536
| |
| − | Sector size: 4096
| |
| − | Filesystem size: 512.00MiB
| |
| − | Block group profiles:
| |
| − | Data: single 8.00MiB
| |
| − | Metadata: DUP 40.00MiB
| |
| − | System: DUP 12.00MiB
| |
| − | SSD detected: no
| |
| − | Incompat features: extref, skinny-metadata
| |
| − | Number of devices: 1
| |
| − | Devices:
| |
| − | ID SIZE PATH
| |
| − | 1 512.00MiB /dev/loop0</pre>
| |
| − | <pre># mount /dev/loop0 /mnt/
| |
| − | mount: mount /dev/loop0 on /mnt failed: No space left on device</pre>
| |
| − | <p>The ENOSPC occurs during the creation of the UUID tree. This is caused
| |
| − | by large metadata blocks and space reservation strategy that allocates more
| |
| − | than can fit into the filesystem.</p>
| |
| − | ==AVAILABILITY==
| |
| − |
| |
| − | <p><b>mkfs.btrfs</b> is part of btrfs-progs.
| |
| − | Please refer to the btrfs wiki http://btrfs.wiki.kernel.org for
| |
| − | further details.</p>
| |
| − | ==SEE ALSO==
| |
| − |
| |
| − | <p>[[Manpage/btrfs|btrfs(5)]],
| |
| − | [[Manpage/btrfs|btrfs(8)]],
| |
| − | [[Manpage/btrfs-balance|btrfs-balance(8)]],
| |
| − | [http://man7.org/linux/man-pages/man8/wipefs.8.html wipefs(8)]</p>
| |
| − | [[Category:Manpage]]
| |
