mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/kdave/btrfs-progs.git
synced 2024-11-27 06:04:30 +08:00
btrfs-progs: docs: fix typos
Namely change eg. to e.g. and ie. to i.e. Signed-off-by: David Sterba <dsterba@suse.com>
This commit is contained in:
David Sterba
parent
900d56f1b9
commit
c0360b4735
@ -1,7 +1,7 @@
|
||||
Auto-repair on read
|
||||
===================
|
||||
|
||||
Data or metadata that are found to be damaged (eg. because the checksum does
|
||||
Data or metadata that are found to be damaged (e.g. because the checksum does
|
||||
not match) at the time they're read from the device can be salvaged in case the
|
||||
filesystem has another valid copy when using block group profile with redundancy
|
||||
(DUP, RAID1, RAID5/6). The correct data are returned to the user application
|
||||
|
||||
@ -43,7 +43,7 @@
|
||||
* why: running commands from scripts or among many other commands should be
|
||||
noticeable due to progress tracking or for analysis if something goes wrong
|
||||
* there's a global option to make the commands silent `btrfs -q subcommand`,
|
||||
this can be easily scripted eg. storing the global verbosity option in a
|
||||
this can be easily scripted e.g. storing the global verbosity option in a
|
||||
variable, `btrfs $quiet subcommand` and then enabling or disabling as needed
|
||||
* line length should not exceed 80 columns if possible but this is not a strict
|
||||
limit and we want to put the relevant information there rather abbreviate too
|
||||
@ -53,7 +53,7 @@
|
||||
|
||||
* numeric values are not quoted
|
||||
* string values are quoted if they would be confused when parsed word by word
|
||||
(eg. file paths)
|
||||
(e.g. file paths)
|
||||
* quoting is by single apostrophe on both ends
|
||||
* all messages follow a few known and understood schemes
|
||||
|
||||
|
||||
@ -41,7 +41,7 @@ File based deduplication
|
||||
------------------------
|
||||
|
||||
The tool takes a list of files and tries to find duplicates among data only
|
||||
from that files. This is suitable eg. for files that originated from the same
|
||||
from that files. This is suitable e.g. for files that originated from the same
|
||||
base image, source of a reflinked file. Optionally the tools could track a
|
||||
database of hashes and allow to deduplicate blocks from more files, or use that
|
||||
for repeated runs and update the database incrementally.
|
||||
@ -61,7 +61,7 @@ Safety of block comparison
|
||||
|
||||
The deduplication inside the filesystem is implemented as an ``ioctl`` that takes
|
||||
a source file, destination file and the range. The blocks from both files are
|
||||
compared for exact match before merging to the same range (ie. there's no
|
||||
compared for exact match before merging to the same range (i.e. there's no
|
||||
hash based comparison). Pages representing the extents in memory are locked
|
||||
prior to deduplication and prevent concurrent modification by buffered writes
|
||||
or mmaped writes.
|
||||
@ -70,7 +70,7 @@ Limitations, compatibility
|
||||
--------------------------
|
||||
|
||||
Files that are subject do deduplication must have the same status regarding
|
||||
COW, ie. both regular COW files with checksums, or both NOCOW, or files that
|
||||
COW, i.e. both regular COW files with checksums, or both NOCOW, or files that
|
||||
are COW but don't have checksums (NODATASUM attribute is set).
|
||||
|
||||
If the deduplication is in progress on any file in the filesystem, the *send*
|
||||
|
||||
@ -22,7 +22,7 @@ happen together with other data and the result depends on the remaining free
|
||||
space layout and fragmentation.
|
||||
|
||||
.. warning::
|
||||
Defragmentation does not preserve extent sharing, eg. files created by **cp
|
||||
Defragmentation does not preserve extent sharing, e.g. files created by **cp
|
||||
--reflink** or existing on multiple snapshots. Due to that the data space
|
||||
consumption may increase.
|
||||
|
||||
|
||||
@ -23,7 +23,7 @@ Quotation in subcommands:
|
||||
- exact syntax: monotype ``usage=0``
|
||||
- reference to arguments etc: *italics*
|
||||
- command reference: bold ``btrfs filesystem show``
|
||||
- subcommand names should be spelled in full, ie. *filesystem* instead of *fi*
|
||||
- subcommand names should be spelled in full, i.e. *filesystem* instead of *fi*
|
||||
- section references: italics *EXAMPLES*
|
||||
|
||||
- argument name in option description: caps in angle brackets <NAME>
|
||||
|
||||
@ -212,7 +212,7 @@ features see [[Status]] page.
|
||||
<i>ref-verify</i>, must be built with CONFIG_BTRFS_FS_REF_VERIFY.
|
||||
|
||||
4.15 - zlib level
|
||||
Allow to set the zlib compression level via mount option, eg. like
|
||||
Allow to set the zlib compression level via mount option, e.g. like
|
||||
*compress=zlib:9*. The levels match the default zlib compression
|
||||
levels. The default is 3.
|
||||
|
||||
@ -289,7 +289,7 @@ features see [[Status]] page.
|
||||
if the kernel module is reloaded.
|
||||
|
||||
5.1 - zstd level
|
||||
Allow to set the zstd compression level via mount option, eg. like
|
||||
Allow to set the zstd compression level via mount option, e.g. like
|
||||
*compress=zstd:9*. The levels match the default zstd compression
|
||||
levels. The default is 3, maximum is 15.
|
||||
|
||||
@ -403,7 +403,7 @@ features see [[Status]] page.
|
||||
DUP metadata works with zoned mode
|
||||
|
||||
5.18 - encoded data ioctl
|
||||
New ioctls to read and write pre-encoded data (ie. no transformation
|
||||
New ioctls to read and write pre-encoded data (i.e. no transformation
|
||||
and directly written as extents), now works for compressed data
|
||||
|
||||
5.18 - *removed balance ioctl v1*
|
||||
|
||||
@ -4,12 +4,12 @@ Glossary
|
||||
Terms in *italics* also appear in this glossary.
|
||||
|
||||
allocator
|
||||
Usually *allocator* means the *block* allocator, ie. the logic
|
||||
Usually *allocator* means the *block* allocator, i.e. the logic
|
||||
inside filesystem which decides where to place newly allocated blocks
|
||||
in order to maintain several constraints (like data locality, low
|
||||
fragmentation).
|
||||
|
||||
In btrfs, allocator may also refer to *chunk* allocator, ie. the
|
||||
In btrfs, allocator may also refer to *chunk* allocator, i.e. the
|
||||
logic behind placing chunks on devices.
|
||||
|
||||
balance
|
||||
@ -30,7 +30,7 @@ barrier
|
||||
|
||||
block
|
||||
A single physically and logically contiguous piece of storage on a
|
||||
device, of size eg. 4K.
|
||||
device, of size e.g. 4K.
|
||||
|
||||
block group
|
||||
The unit of allocation of space in btrfs. A block group is laid out on
|
||||
@ -47,7 +47,7 @@ B-tree
|
||||
refers to its use of B-trees.
|
||||
|
||||
btrfsck
|
||||
Tool in *btrfs-progs* that checks a filesystem *offline* (ie.
|
||||
Tool in *btrfs-progs* that checks a filesystem *offline* (i.e.
|
||||
unmounted), and reports on any errors in the filesystem structures it
|
||||
finds. By default the tool runs in read-only mode as fixing errors is
|
||||
potentially dangerous. See also *scrub*.
|
||||
@ -312,7 +312,7 @@ system array
|
||||
top-level subvolume
|
||||
The *subvolume* at the very top of the filesystem. This is the only
|
||||
subvolume present in a newly-created btrfs filesystem, and internally has ID 5,
|
||||
otherwise could be referenced as 0 (eg. within the *set-default* subcommand of
|
||||
otherwise could be referenced as 0 (e.g. within the *set-default* subcommand of
|
||||
*btrfs*).
|
||||
|
||||
transaction
|
||||
|
||||
@ -2,7 +2,7 @@ Inline files
|
||||
============
|
||||
|
||||
Files up to some size can be stored in the metadata section ("inline" in the
|
||||
b-tree nodes), ie. no separate blocks for the extents. The default limit is
|
||||
b-tree nodes), i.e. no separate blocks for the extents. The default limit is
|
||||
2048 bytes and can be configured by mount option ``max_inline``. The data of
|
||||
inlined files can be also compressed as long as they fit into the b-tree nodes.
|
||||
|
||||
@ -11,7 +11,7 @@ namely with different level of integrity, this also affects the inlined files.
|
||||
It can be completely disabled by mounting with ``max_inline=0``. The upper
|
||||
limit is either the size of b-tree node or the page size of the host.
|
||||
|
||||
An inline file can be identified by enumerating the extents, eg. by the tool
|
||||
An inline file can be identified by enumerating the extents, e.g. by the tool
|
||||
``filefrag``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -9,14 +9,14 @@ it generates a difference relative to that set (*incremental mode*).
|
||||
|
||||
Receive on the other hand takes the stream and reconstructs a subvolume with
|
||||
files and directories equivalent to the filesystem that was used to produce the
|
||||
stream. The result is not exactly 1:1, eg. inode numbers can be different and
|
||||
stream. The result is not exactly 1:1, e.g. inode numbers can be different and
|
||||
other unique identifiers can be different (like the subvolume UUIDs). The full
|
||||
mode starts with an empty subvolume, creates all the files and then turns the
|
||||
subvolume to read-only. At this point it could be used as a starting point for a
|
||||
future incremental send stream, provided it would be generated from the same
|
||||
source subvolume on the other filesystem.
|
||||
|
||||
The stream is a sequence of encoded commands that change eg. file metadata
|
||||
The stream is a sequence of encoded commands that change e.g. file metadata
|
||||
(owner, permissions, extended attributes), data extents (create, clone,
|
||||
truncate), whole file operations (rename, delete). The stream can be sent over
|
||||
network, piped directly to the receive command or saved to a file. Each command
|
||||
|
||||
@ -12,7 +12,7 @@ requests that go to Linus and for linux-next integration:
|
||||
* https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git -- pull requests, branch *for-next* gets pulled to the linux-next tree
|
||||
|
||||
The following git repositories are used for development and are updated with
|
||||
patches from the mailinglist:
|
||||
patches from the mailing list:
|
||||
|
||||
* https://github.com/kdave/btrfs-devel
|
||||
* https://gitlab.com/kdave/btrfs-devel
|
||||
@ -22,9 +22,9 @@ Branches are usually pushed to both repositories, either can be used.
|
||||
There are:
|
||||
|
||||
* main queue with patches for next development cycle (branch name *misc-next*)
|
||||
* queue with patches for current release cycle (the name has the version, eg *for-4.15* or *misc-4.15*).
|
||||
* topic branches, eg. from a patchset picked from mailinglist
|
||||
* snapshots of *for-next*, that contain all of the above (eg. for-next-20200512)
|
||||
* queue with patches for current release cycle (the name has the version, e.g. *for-4.15* or *misc-4.15*).
|
||||
* topic branches, e.g. from a patchset picked from mailing list
|
||||
* snapshots of *for-next*, that contain all of the above (e.g. for-next-20200512)
|
||||
|
||||
Note that the branches get rebased. The base point for patches depend on the
|
||||
development phase. See [[Developer%27s_FAQ#Development_schedule]].
|
||||
@ -68,8 +68,8 @@ Note to GitHub users
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The pull requests will not be accepted directly, the preferred way is to send
|
||||
patches to the mailinglist instead. You can link to a branch in any git
|
||||
repository if the mails do not make it to the mailinglist or for convenience.
|
||||
patches to the mailing list instead. You can link to a branch in any git
|
||||
repository if the mails do not make it to the mailing list or for convenience.
|
||||
|
||||
The development model of btrfs-progs shares a lot with the kernel model. The
|
||||
github way is different in some ways. We, the upstream community, expect that
|
||||
@ -96,8 +96,8 @@ tasks on btrfs. This is at:
|
||||
|
||||
https://github.com/kdave/btrfsmaintenance/
|
||||
|
||||
Patches sent to mailinglist
|
||||
---------------------------
|
||||
Patches sent to mailing list
|
||||
----------------------------
|
||||
|
||||
A convenient interface to get an overview of patches and the related mail
|
||||
discussions can be found at
|
||||
|
||||
@ -44,7 +44,7 @@ The following features has some limitations for subpage:
|
||||
non-subpage mount for certain corner cases, it's way easier to create such
|
||||
mixed extents for subpage.
|
||||
|
||||
Thus max_inline mount option will be sliently ignored for subpage mounts,
|
||||
Thus max_inline mount option will be silently ignored for subpage mounts,
|
||||
and it always acts as "max_inline=0".
|
||||
|
||||
- Compression write is limited to page aligned ranges
|
||||
|
||||
@ -63,8 +63,8 @@ The checks
|
||||
----------
|
||||
|
||||
As implemented right now, the metadata consistency is limited to one b-tree node
|
||||
and what items are stored there, ie. there's no extensive or broad check done
|
||||
eg. against other data structures in other b-tree nodes. This still provides
|
||||
and what items are stored there, i.e. there's no extensive or broad check done
|
||||
e.g. against other data structures in other b-tree nodes. This still provides
|
||||
enough opportunities to verify consistency of individual items, besides verifying
|
||||
general validity of the items like the length or offset. The b-tree items are
|
||||
also coupled with a key so proper key ordering is also part of the check and can
|
||||
@ -79,7 +79,7 @@ Reporting problems
|
||||
------------------
|
||||
|
||||
In many cases the bug is caused by hardware and cannot be automatically fixed
|
||||
by *btrfs check --repair*, so do not try that without being adviced to. Even if
|
||||
by *btrfs check --repair*, so do not try that without being advised to. Even if
|
||||
the error is unfixable it's useful to report it, either to validate the cause
|
||||
but also to give more ideas how to improve the tree checker. Please consider
|
||||
reporting it to the mailing list *linux-btrfs@vger.kernel.org*.
|
||||
|
||||
@ -16,7 +16,7 @@ SUBCOMMAND
|
||||
|
||||
cancel <path>
|
||||
cancels a running or paused balance, the command will block and wait until the
|
||||
current blockgroup being processed completes
|
||||
current block group being processed completes
|
||||
|
||||
Since kernel 5.7 the response time of the cancellation is significantly
|
||||
improved, on older kernels it might take a long time until currently
|
||||
@ -28,7 +28,7 @@ pause <path>
|
||||
|
||||
resume <path>
|
||||
resume interrupted balance, the balance status must be stored on the filesystem
|
||||
from previous run, eg. after it was paused or forcibly interrupted and mounted
|
||||
from previous run, e.g. after it was paused or forcibly interrupted and mounted
|
||||
again with *skip_balance*
|
||||
|
||||
start [options] <path>
|
||||
@ -38,7 +38,7 @@ start [options] <path>
|
||||
|
||||
.. note::
|
||||
The balance command without filters will basically move everything in the
|
||||
filesystem to a new physical location on devices (ie. it does not affect 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
|
||||
@ -63,7 +63,7 @@ start [options] <path>
|
||||
act on system chunks (requires *-f*), see *FILTERS* section for details about *filters*.
|
||||
|
||||
-f
|
||||
force a reduction of metadata integrity, eg. when going from *raid1* to
|
||||
force a reduction of metadata integrity, e.g. when going from *raid1* to
|
||||
*single*, or skip safety timeout when the target conversion profile is *raid5*
|
||||
or *raid6*
|
||||
|
||||
@ -149,7 +149,7 @@ Let's use the following real life example and start with the output:
|
||||
Roughly calculating for data, *75G - 64G = 11G*, the used/total ratio is
|
||||
about *85%*. How can we can interpret that:
|
||||
|
||||
* chunks are filled by 85% on average, ie. the *usage* filter with anything
|
||||
* chunks are filled by 85% on average, i.e. the *usage* filter with anything
|
||||
smaller than 85 will likely not affect anything
|
||||
* in a more realistic scenario, the space is distributed unevenly, we can
|
||||
assume there are completely used chunks and the remaining are partially filled
|
||||
@ -188,7 +188,7 @@ usage filter.
|
||||
GlobalReserve, single: total=512.00MiB, used=0.00B
|
||||
|
||||
Now the used/total ratio is about 94% and we moved about *74G - 68G = 6G* of
|
||||
data to the remaining blockgroups, ie. the 6GiB are now free of filesystem
|
||||
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.
|
||||
|
||||
We can do a similar exercise with the metadata block groups, but this should
|
||||
@ -210,7 +210,7 @@ reflinks updated frequently.
|
||||
|
||||
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, ie. lots of IO. As running out of metadata
|
||||
updating more metadata structures, i.e. lots of IO. As running out of metadata
|
||||
space is a more severe problem, it's not necessary to keep the utilization
|
||||
ratio too high. For the purpose of this example, let's see the effects of
|
||||
further compaction:
|
||||
|
||||
@ -139,7 +139,7 @@ DANGEROUS OPTIONS
|
||||
--force
|
||||
allow work on a mounted filesystem. Note that this should work fine on a
|
||||
quiescent or read-only mounted filesystem but may crash if the device is
|
||||
changed externally, eg. by the kernel module. Repair without mount checks is
|
||||
changed externally, e.g. by the kernel module. Repair without mount checks is
|
||||
not supported right now.
|
||||
|
||||
This option also skips the delay and warning in the repair mode (see
|
||||
|
||||
@ -25,7 +25,7 @@ add [-Kf] <device> [<device>...] <path>
|
||||
If applicable, a whole device discard (TRIM) operation is performed prior to
|
||||
adding the device. A device with existing filesystem detected by ``blkid(8)``
|
||||
will prevent device addition and has to be forced. Alternatively the filesystem
|
||||
can be wiped from the device using eg. the ``wipefs(8)`` tool.
|
||||
can be wiped from the device using e.g. the ``wipefs(8)`` tool.
|
||||
|
||||
The operation is instant and does not affect existing data. The operation merely
|
||||
adds the device to the filesystem structures and creates some block groups
|
||||
@ -157,7 +157,7 @@ usage [options] <path> [<path>...]::
|
||||
* *Device size* -- size of the device as seen by the filesystem (may be
|
||||
different than actual device size)
|
||||
* *Device slack* -- portion of device not used by the filesystem but
|
||||
still available in the physical space provided by the device, eg.
|
||||
still available in the physical space provided by the device, e.g.
|
||||
after a device shrink
|
||||
* *Data,single*, *Metadata,single*, *System,single* -- in general, list
|
||||
of block group type (Data, Metadata, System) and profile (single,
|
||||
@ -224,7 +224,7 @@ flush_io_errs
|
||||
corruption_errs
|
||||
A block checksum mismatched or a corrupted metadata header was found.
|
||||
generation_errs
|
||||
The block generation does not match the expected value (eg. stored in the
|
||||
The block generation does not match the expected value (e.g. stored in the
|
||||
parent node).
|
||||
|
||||
Since kernel 5.14 the device stats are also available in textual form in
|
||||
|
||||
@ -41,11 +41,11 @@ df [options] <path>
|
||||
below.
|
||||
* *single* -- the allocation profile, defined at mkfs time
|
||||
* *total* -- sum of space reserved for all allocation profiles of the
|
||||
given type, ie. all Data/single. Note that it's not total size of
|
||||
given type, i.e. all Data/single. Note that it's not total size of
|
||||
filesystem.
|
||||
* *used* -- sum of used space of the above, ie. file extents, metadata blocks
|
||||
* *used* -- sum of used space of the above, i.e. file extents, metadata blocks
|
||||
|
||||
*GlobalReserve* is an artificial and internal emergency space. It is used eg.
|
||||
*GlobalReserve* is an artificial and internal emergency space. It is used e.g.
|
||||
when the filesystem is full. Its *total* size is dynamic based on the
|
||||
filesystem size, usually not larger than 512MiB, *used* may fluctuate.
|
||||
|
||||
@ -124,7 +124,7 @@ defragment [options] <file>|<dir> [<file>|<dir>...]
|
||||
This will limit the amount of dirty data to current file, otherwise the amount
|
||||
accumulates from several files and will increase system load. This can also lead
|
||||
to ENOSPC if there's too much dirty data to write and it's not possible to make
|
||||
the reservations for the new data (ie. how the COW design works).
|
||||
the reservations for the new data (i.e. how the COW design works).
|
||||
|
||||
-s <start>[kKmMgGtTpPeE]
|
||||
defragmentation will start from the given offset, default is beginning of a file
|
||||
@ -332,11 +332,11 @@ usage [options] <path> [<path>...]
|
||||
* *Free (statfs, df)* -- the amount of space available for data as
|
||||
reported by the **statfs** syscall, also returned as *Avail* in the
|
||||
output of **df**. The value is calculated in a different way and may
|
||||
not match the estimate in some cases (eg. multiple profiles).
|
||||
not match the estimate in some cases (e.g. multiple profiles).
|
||||
* *Data ratio* -- ratio of total space for data including redundancy or
|
||||
parity to the effectively usable data space, eg. single is 1.0, RAID1
|
||||
parity to the effectively usable data space, e.g. single is 1.0, RAID1
|
||||
is 2.0 and for RAID5/6 it depends on the number of devices
|
||||
* *Metadata ratio* -- dtto, for metadata
|
||||
* *Metadata ratio* -- ditto, for metadata
|
||||
* *Global reserve* -- portion of metadata currently used for global
|
||||
block reserve, used for emergency purposes (like deletion on a full
|
||||
filesystem)
|
||||
@ -352,7 +352,7 @@ usage [options] <path> [<path>...]
|
||||
Device zone size: 256.00MiB
|
||||
|
||||
* *Device zone unusable* -- sum of of space that's been used in the
|
||||
past but now is not due to COW and not referenced anymory, the chunks
|
||||
past but now is not due to COW and not referenced anymore, the chunks
|
||||
have to be reclaimed and zones reset to make it usable again
|
||||
* *Device zone size* -- the reported zone size of the host-managed
|
||||
device, same for all devices
|
||||
@ -448,7 +448,7 @@ specify the devid though.
|
||||
**$ btrfs filesystem resize 1:max /path**
|
||||
|
||||
Let's assume that devid 1 exists and the filesystem does not occupy the whole
|
||||
block device, eg. it has been enlarged and we want to grow the filesystem. By
|
||||
block device, e.g. it has been enlarged and we want to grow the filesystem. By
|
||||
simply using *max* as size we will achieve that.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -39,7 +39,7 @@ OPTIONS
|
||||
-s
|
||||
Sanitize the file names when generating the image. One -s means just
|
||||
generate random garbage, which means that the directory indexes won't match up
|
||||
since the hashes won't match with the garbage filenames. Using -ss will
|
||||
since the hashes won't match with the garbage filenames. Using *-s* will
|
||||
calculate a collision for the filename so that the hashes match, and if it
|
||||
can't calculate a collision then it will just generate garbage. The collision
|
||||
calculator is very time and CPU intensive so only use it if you are having
|
||||
|
||||
@ -80,9 +80,9 @@ dump-tree [options] <device> [device...]
|
||||
-d|--device
|
||||
print only device-related information: tree root, chunk and device trees
|
||||
-r|--roots
|
||||
print only short root node information, ie. the root tree keys
|
||||
print only short root node information, i.e. the root tree keys
|
||||
-R|--backups
|
||||
same as *--roots* plus print backup root info, ie. the backup root keys and
|
||||
same as *--roots* plus print backup root info, i.e. the backup root keys and
|
||||
the respective tree root block offset
|
||||
-u|--uuid
|
||||
print only the uuid tree information, empty output if the tree does not exist
|
||||
@ -132,16 +132,16 @@ dump-tree [options] <device> [device...]
|
||||
The tree id name recognition rules:
|
||||
|
||||
* case does not matter
|
||||
* the C source definition, eg. BTRFS_ROOT_TREE_OBJECTID
|
||||
* short forms without BTRFS\_ prefix, without _TREE and _OBJECTID suffix, eg. ROOT_TREE, ROOT
|
||||
* convenience aliases, eg. DEVICE for the DEV tree, CHECKSUM for CSUM
|
||||
* the C source definition, e.g. BTRFS_ROOT_TREE_OBJECTID
|
||||
* short forms without BTRFS\_ prefix, without _TREE and _OBJECTID suffix, e.g. ROOT_TREE, ROOT
|
||||
* convenience aliases, e.g. DEVICE for the DEV tree, CHECKSUM for CSUM
|
||||
* unrecognized ID is an error
|
||||
|
||||
inode-resolve [-v] <ino> <path>
|
||||
(needs root privileges)
|
||||
|
||||
resolve paths to all files with given inode number *ino* in a given subvolume
|
||||
at *path*, ie. all hardlinks
|
||||
at *path*, i.e. all hardlinks
|
||||
|
||||
``Options``
|
||||
|
||||
@ -200,7 +200,7 @@ min-dev-size [options] <path>
|
||||
|
||||
rootid <path>
|
||||
for a given file or directory, return the containing tree root id, but for a
|
||||
subvolume itself return its own tree id (ie. subvol id)
|
||||
subvolume itself return its own tree id (i.e. subvol id)
|
||||
|
||||
.. note::
|
||||
The result is undefined for the so-called empty subvolumes (identified by
|
||||
|
||||
@ -109,7 +109,7 @@ mixed_backref
|
||||
mixed_groups
|
||||
(since: 2.6.37)
|
||||
|
||||
mixed data and metadata block groups, ie. the data and metadata are not
|
||||
mixed data and metadata block groups, i.e. the data and metadata are not
|
||||
separated and occupy the same block groups, this mode is suitable for small
|
||||
volumes as there are no constraints how the remaining space should be used
|
||||
(compared to the split mode, where empty metadata space cannot be used for data
|
||||
@ -252,7 +252,7 @@ numbers 10 and 234 (the device can be found under the 'misc' category).
|
||||
The device accepts some ioctl calls that can perform following actions on the
|
||||
filesystem module:
|
||||
|
||||
* scan devices for btrfs filesystem (ie. to let multi-device filesystems mount
|
||||
* scan devices for btrfs filesystem (i.e. to let multi-device filesystems mount
|
||||
automatically) and register them with the kernel module
|
||||
* similar to scan, but also wait until the device scanning process is finished
|
||||
for a given filesystem
|
||||
@ -260,7 +260,7 @@ filesystem module:
|
||||
|
||||
The device is created when btrfs is initialized, either as a module or a
|
||||
built-in functionality and makes sense only in connection with that. Running
|
||||
eg. mkfs without the module loaded will not register the device and will
|
||||
e.g. mkfs without the module loaded will not register the device and will
|
||||
probably warn about that.
|
||||
|
||||
In rare cases when the module is loaded but the device is not present (most
|
||||
@ -373,7 +373,7 @@ general may be stored on some other devices due to the way RAID1 works on
|
||||
btrfs, unlike on a striped profile (similar to *raid0*) that would need all
|
||||
devices all the time.
|
||||
|
||||
The space allocation pattern and consumption is different (eg. on N devices):
|
||||
The space allocation pattern and consumption is different (e.g. on N devices):
|
||||
for *raid5* as an example, a 1GiB chunk is reserved on each device, while with
|
||||
*raid1* there's each 1GiB chunk stored on 2 devices. The consumption of each
|
||||
1GiB of used metadata is then *N * 1GiB* for vs *2 * 1GiB*. Using *raid1*
|
||||
@ -384,8 +384,8 @@ Missing/incomplete support
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
When RAID56 is on the same filesystem with different raid profiles, the space
|
||||
reporting is inaccurate, eg. **df**, **btrfs filesystem df** or **btrfs filesystem
|
||||
usage**. When there's only a one profile per block group type (eg. raid5 for data)
|
||||
reporting is inaccurate, e.g. **df**, **btrfs filesystem df** or **btrfs filesystem
|
||||
usage**. When there's only a one profile per block group type (e.g. raid5 for data)
|
||||
the reporting is accurate.
|
||||
|
||||
When scrub is started on a RAID56 filesystem, it's started on all devices that
|
||||
|
||||
@ -20,9 +20,8 @@ btrfs properties instead of using the traditional method like ``chattr(1)`` or
|
||||
Object types
|
||||
^^^^^^^^^^^^
|
||||
|
||||
|
||||
A property might apply to several object types so in some cases it's necessary
|
||||
to specify that explicity, however it's not needed in the most common case of
|
||||
to specify that explicitly, however it's not needed in the most common case of
|
||||
files and directories.
|
||||
|
||||
The subcommands take parameter *-t*, use first letter as a shortcut (*f/s/d/i*)
|
||||
@ -43,7 +42,7 @@ compression
|
||||
- *lzo*
|
||||
- *zlib*
|
||||
- *zstd*
|
||||
- *no* or *none* - disable compresssion (equivalent to ``chattr +m``)
|
||||
- *no* or *none* - disable compression (equivalent to ``chattr +m``)
|
||||
- *""* (empty string) - set the default value
|
||||
|
||||
.. note::
|
||||
|
||||
@ -156,7 +156,7 @@ show [options] <path>
|
||||
QUOTA RESCAN
|
||||
------------
|
||||
|
||||
The rescan reads all extent sharing metadata and updates the respective qgoups
|
||||
The rescan reads all extent sharing metadata and updates the respective qgroups
|
||||
accordingly.
|
||||
|
||||
The information consists of bytes owned exclusively (*excl*) or shared/referred
|
||||
|
||||
@ -54,7 +54,7 @@ A subvolume is made read-only after the receiving process finishes successfully
|
||||
the root mount point of the destination filesystem
|
||||
|
||||
By default the mountpoint is searched in */proc/self/mounts*.
|
||||
If */proc* is not accessible, eg. in a chroot environment, use this option to
|
||||
If */proc* is not accessible, e.g. in a chroot environment, use this option to
|
||||
tell us where this filesystem is mounted.
|
||||
|
||||
--force-decompress
|
||||
|
||||
@ -74,7 +74,7 @@ zero-log <device>
|
||||
|
||||
This command will clear the filesystem log tree. This may fix a specific
|
||||
set of problem when the filesystem mount fails due to the log replay. See below
|
||||
for sample stacktraces that may show up in system log.
|
||||
for sample stack traces that may show up in system log.
|
||||
|
||||
The common case where this happens was fixed a long time ago,
|
||||
so it is unlikely that you will see this particular problem, but the command is
|
||||
|
||||
@ -52,7 +52,7 @@ OPTIONS
|
||||
ignore errors during restoration and continue
|
||||
|
||||
-o|--overwrite
|
||||
overwrite directories/files in *path*, eg. for repeated runs
|
||||
overwrite directories/files in *path*, e.g. for repeated runs
|
||||
|
||||
-t <bytenr>
|
||||
use *bytenr* to read the root tree
|
||||
|
||||
@ -12,7 +12,7 @@ DESCRIPTION
|
||||
Destructively overwrite all copies of the superblock with a specified copy.
|
||||
This helps in certain cases, for example when write barriers were disabled
|
||||
during a power failure and not all superblocks were written, or if the primary
|
||||
superblock is damaged, eg. accidentally overwritten.
|
||||
superblock is damaged, e.g. accidentally overwritten.
|
||||
|
||||
The filesystem specified by *device* must not be mounted.
|
||||
|
||||
|
||||
@ -62,7 +62,7 @@ limit=<number>, limit=<range>
|
||||
stripes=<range>
|
||||
Balance only block groups which have the given number of stripes. The parameter
|
||||
is a range specified as *start..end*. Makes sense for block group profiles that
|
||||
utilize striping, ie. RAID0/10/5/6. The range minimum and maximum are
|
||||
utilize striping, i.e. RAID0/10/5/6. The range minimum and maximum are
|
||||
inclusive.
|
||||
|
||||
soft
|
||||
|
||||
@ -8,7 +8,7 @@ Files are not defragmented nor recompressed, file extents are preserved
|
||||
but the physical location on devices will change.
|
||||
|
||||
The balance operation is cancellable by the user. The on-disk state of the
|
||||
filesystem is always consistent so an unexpected interruption (eg. system crash,
|
||||
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 *skip_balance* is specified.
|
||||
@ -29,11 +29,11 @@ metadata, system). Note that changing only the *system* type needs the force
|
||||
option. Otherwise *system* gets automatically converted whenever *metadata*
|
||||
profile is converted.
|
||||
|
||||
When metadata redundancy is reduced (eg. from RAID1 to single) the force option
|
||||
When metadata redundancy is reduced (e.g. from RAID1 to single) the force option
|
||||
is also required and it is noted in system log.
|
||||
|
||||
.. note::
|
||||
The balance operation needs enough work space, ie. space that is completely
|
||||
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 *ENOSPC* for more details.
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ You can have a single btrfs mount point that has some files that are
|
||||
uncompressed, some that are compressed with LZO, some with ZLIB, for instance
|
||||
(though you may not want it that way, it is supported).
|
||||
|
||||
Once the compression is set, all newly written data will be compressed, ie.
|
||||
Once the compression is set, all newly written data will be compressed, i.e.
|
||||
existing data are untouched. Data are split into smaller chunks (128KiB) before
|
||||
compression to make random rewrites possible without a high performance hit. Due
|
||||
to the increased number of extents the metadata consumption is higher. The
|
||||
|
||||
@ -29,14 +29,14 @@ fragmentation, and also because the metadata blocks are bound to the original
|
||||
free space layout.
|
||||
|
||||
Due to different constraints, it is only possible to convert filesystems that
|
||||
have a supported data block size (ie. the same that would be valid for
|
||||
have a supported data block size (i.e. the same that would be valid for
|
||||
**mkfs.btrfs**). This is typically the system page size (4KiB on x86_64
|
||||
machines).
|
||||
|
||||
**BEFORE YOU START**
|
||||
|
||||
The source filesystem must be clean, eg. no journal to replay or no repairs
|
||||
needed. The respective **fsck** utility must be run on the source filessytem prior
|
||||
The source filesystem must be clean, e.g. no journal to replay or no repairs
|
||||
needed. The respective **fsck** utility must be run on the source filesystem prior
|
||||
to conversion. Please refer to the manual pages in case you encounter problems.
|
||||
|
||||
For ext2/3/4:
|
||||
|
||||
@ -5,7 +5,7 @@ maximum symlink target length
|
||||
depends on the *nodesize* value, for 4KiB it's 3949 bytes, for larger nodesize
|
||||
it's 4095 due to the system limit PATH_MAX
|
||||
|
||||
The symlink target may not be a valid path, ie. the path name components
|
||||
The symlink target may not be a valid path, i.e. the path name components
|
||||
can exceed the limits (NAME_MAX), there's no content validation at ``symlink(3)``
|
||||
creation.
|
||||
|
||||
|
||||
@ -7,7 +7,7 @@ data on top of the storage device.*
|
||||
|
||||
The filesystem assumes several features or limitations of the storage device
|
||||
and utilizes them or applies measures to guarantee reliability. BTRFS in
|
||||
particular is based on a COW (copy on write) mode of writing, ie. not updating
|
||||
particular is based on a COW (copy on write) mode of writing, i.e. not updating
|
||||
data in place but rather writing a new copy to a different location and then
|
||||
atomically switching the pointers.
|
||||
|
||||
@ -41,7 +41,7 @@ When things go wrong
|
||||
|
||||
**No or partial atomicity of block reads/writes (1)**
|
||||
|
||||
- *Problem*: a partial block contents is written (*torn write*), eg. due to a
|
||||
- *Problem*: a partial block contents is written (*torn write*), e.g. due to a
|
||||
power glitch or other electronics failure during the read/write
|
||||
- *Detection*: checksum mismatch on read
|
||||
- *Repair*: use another copy or rebuild from multiple blocks using some encoding
|
||||
@ -188,7 +188,7 @@ remapping and garbage collection of used memory cells. Due to the additional
|
||||
processing there are measures to verity the data e.g. by ECC codes.
|
||||
|
||||
The observations of failing SSDs show that the whole electronic fails at once
|
||||
or affects a lot of data (eg. stored on one chip). Recovering such data
|
||||
or affects a lot of data (e.g. stored on one chip). Recovering such data
|
||||
may need specialized equipment and reading data repeatedly does not help as
|
||||
it's possible with HDDs.
|
||||
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
This section describes mount options specific to BTRFS. For the generic mount
|
||||
options please refer to ``mount(8)`` manpage. The options are sorted alphabetically
|
||||
options please refer to ``mount(8)`` manual page. The options are sorted alphabetically
|
||||
(discarding the *no* prefix).
|
||||
|
||||
.. note::
|
||||
@ -11,7 +11,7 @@ options please refer to ``mount(8)`` manpage. The options are sorted alphabetica
|
||||
correctly within the Linux VFS framework.
|
||||
|
||||
Mount options are processed in order, only the last occurrence of an option
|
||||
takes effect and may disable other options due to constraints (see eg.
|
||||
takes effect and may disable other options due to constraints (see e.g.
|
||||
*nodatacow* and *compress*). The output of **mount** command shows which options
|
||||
have been applied.
|
||||
|
||||
@ -144,7 +144,7 @@ datasum, nodatasum
|
||||
(default: on)
|
||||
|
||||
Enable data checksumming for newly created files.
|
||||
*Datasum* implies *datacow*, ie. the normal mode of operation. All files created
|
||||
*Datasum* implies *datacow*, i.e. the normal mode of operation. All files created
|
||||
under *nodatasum* inherit the "no checksums" property, however there's no
|
||||
corresponding file attribute (see ``chattr(1)``).
|
||||
|
||||
@ -164,7 +164,7 @@ degraded
|
||||
missing, for example if a stripe member is completely missing from RAID0.
|
||||
|
||||
Since 4.14, the constraint checks have been improved and are verified on the
|
||||
chunk level, not an the device level. This allows degraded mounts of
|
||||
chunk level, not at the device level. This allows degraded mounts of
|
||||
filesystems with mixed RAID profiles for data and metadata, even if the
|
||||
device number constraints would not be satisfied for some of the profiles.
|
||||
|
||||
@ -179,11 +179,11 @@ degraded
|
||||
device=<devicepath>
|
||||
Specify a path to a device that will be scanned for BTRFS filesystem during
|
||||
mount. This is usually done automatically by a device manager (like udev) or
|
||||
using the **btrfs device scan** command (eg. run from the initial ramdisk). In
|
||||
using the **btrfs device scan** command (e.g. run from the initial ramdisk). In
|
||||
cases where this is not possible the *device* mount option can help.
|
||||
|
||||
.. note::
|
||||
Booting eg. a RAID1 system may fail even if all filesystem's *device*
|
||||
Booting e.g. a RAID1 system may fail even if all filesystem's *device*
|
||||
paths are provided as the actual device nodes may not be discovered by the
|
||||
system at that point.
|
||||
|
||||
@ -228,7 +228,7 @@ fatal_errors=<action>
|
||||
panic
|
||||
*panic()* on a fatal error, depending on other system configuration, this may
|
||||
be followed by a reboot. Please refer to the documentation of kernel boot
|
||||
parameters, eg. *panic*, *oops* or *crashkernel*.
|
||||
parameters, e.g. *panic*, *oops* or *crashkernel*.
|
||||
|
||||
flushoncommit, noflushoncommit
|
||||
(default: off)
|
||||
@ -488,5 +488,3 @@ noatime
|
||||
Note that *noatime* may break applications that rely on atime uptimes like
|
||||
the venerable Mutt (unless you use maildir mailboxes).
|
||||
|
||||
|
||||
|
||||
|
||||
@ -12,7 +12,7 @@ on the fly.
|
||||
On the other hand, the traditional approach has only a poor solution to
|
||||
restrict directories.
|
||||
At installation time, the harddisk can be partitioned so that every directory
|
||||
(eg. /usr, /var/, ...) that needs a limit gets its own partition. The obvious
|
||||
(e.g. /usr, /var/, ...) that needs a limit gets its own partition. The obvious
|
||||
problem is that those limits cannot be changed without a reinstallation. The
|
||||
btrfs subvolume feature builds a bridge. Subvolumes correspond in many ways to
|
||||
partitions, as every subvolume looks like its own filesystem. With subvolume
|
||||
@ -46,7 +46,7 @@ Subvolume quota groups
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The basic notion of the Subvolume Quota feature is the quota group, short
|
||||
qgroup. Qgroups are notated as *level/id*, eg. the qgroup 3/2 is a qgroup of
|
||||
qgroup. Qgroups are notated as *level/id*, e.g. the qgroup 3/2 is a qgroup of
|
||||
level 3. For level 0, the leading '0/' can be omitted.
|
||||
Qgroups of level 0 get created automatically when a subvolume/snapshot gets
|
||||
created. The ID of the qgroup corresponds to the ID of the subvolume, so 0/5
|
||||
@ -164,7 +164,7 @@ Multi-user machine
|
||||
When you have several users on a machine, with home directories probably under
|
||||
/home, you might want to restrict /home as a whole, while restricting every
|
||||
user to an individual limit as well. This is easily accomplished by creating a
|
||||
qgroup for /home , eg. 1/1, and assigning all user subvolumes to it.
|
||||
qgroup for /home , e.g. 1/1, and assigning all user subvolumes to it.
|
||||
Restricting this qgroup will limit /home, while every user subvolume can get
|
||||
its own (lower) limit.
|
||||
|
||||
|
||||
@ -26,7 +26,7 @@ Alternatively, deleting the seeding device from the filesystem can turn it into
|
||||
a normal filesystem, provided that the writable device can also contain all the
|
||||
data from the seeding device.
|
||||
|
||||
The seeding device flag can be cleared again by **btrfstune -f -S 0**, eg.
|
||||
The seeding device flag can be cleared again by **btrfstune -f -S 0**, e.g.
|
||||
allowing to update with newer data but please note that this will invalidate
|
||||
all existing filesystems that use this particular seeding device. This works
|
||||
for some use cases, not for others, and the forcing flag to the command is
|
||||
@ -114,7 +114,7 @@ As a result we have:
|
||||
|
||||
* *sda* is a single seeding device, with its initial contents
|
||||
* *sdb* is a seeding device but requires *sda*, the contents are from the time
|
||||
when *sdb* is made seeding, ie. contents of *sda* with any later changes
|
||||
when *sdb* is made seeding, i.e. contents of *sda* with any later changes
|
||||
* *sdc* last writable, can be made a seeding one the same way as was *sdb*,
|
||||
preserving its contents and depending on *sda* and *sdb*
|
||||
|
||||
|
||||
@ -102,11 +102,11 @@ filesystem but are not meant to be rolled back either (database files, VM
|
||||
images, ...).
|
||||
|
||||
Here we could utilize the snapshotting barrier mentioned above, each directory
|
||||
that stores data to be preserved accross rollbacks is it's own subvolume. This
|
||||
could be eg. ``/var``. Further more-fine grained partitioning could be done, eg.
|
||||
that stores data to be preserved across rollbacks is it's own subvolume. This
|
||||
could be e.g. ``/var``. Further more-fine grained partitioning could be done, e.g.
|
||||
adding separate subvolumes for ``/var/log``, ``/var/cache`` etc.
|
||||
|
||||
That there are separate subvolumes requrires separate actions to take the
|
||||
That there are separate subvolumes requires separate actions to take the
|
||||
snapshots (here it gets disconnected from the system root snapshots). This needs
|
||||
to be taken care of by system tools, installers together with selection of which
|
||||
directories are highly recommended to be separate subvolumes.
|
||||
@ -122,7 +122,7 @@ always affect the whole filesystem:
|
||||
- generic: noatime/relatime/..., nodev, nosuid, ro, rw, dirsync
|
||||
- fs-specific: compress, autodefrag, nodatacow, nodatasum
|
||||
|
||||
An example of whole filesystem options is eg. *space_cache*, *rescue*, *device*,
|
||||
An example of whole filesystem options is e.g. *space_cache*, *rescue*, *device*,
|
||||
*skip_balance*, etc. The exceptional options are *subvol* and *subvolid* that
|
||||
are actually used for mounting a given subvolume and can be specified only once
|
||||
for the mount.
|
||||
|
||||
@ -6,8 +6,8 @@ swap subsystem:
|
||||
* filesystem - must be only single device
|
||||
* filesystem - must have only *single* data profile
|
||||
* swapfile - the containing subvolume cannot be snapshotted
|
||||
* swapfile - must be preallocated (ie. no holes)
|
||||
* swapfile - must be nodatacow (ie. also nodatasum, no compression)
|
||||
* swapfile - must be preallocated (i.e. no holes)
|
||||
* swapfile - must be nodatacow (i.e. also nodatasum, no compression)
|
||||
|
||||
The limitations come namely from the COW-based design and mapping layer of
|
||||
blocks that allows the advanced features like relocation and multi-device
|
||||
@ -28,7 +28,7 @@ swapfile extents or may fail:
|
||||
* device replace - ditto
|
||||
|
||||
When there are no active swapfiles and a whole-filesystem exclusive operation
|
||||
is running (eg. balance, device delete, shrink), the swapfiles cannot be
|
||||
is running (e.g. balance, device delete, shrink), the swapfiles cannot be
|
||||
temporarily activated. The operation must finish first.
|
||||
|
||||
To create and activate a swapfile run the following commands:
|
||||
@ -90,7 +90,7 @@ offset.
|
||||
|
||||
Since version 6.1 there's a command ``btrfs inspect-internal map-swapfile`` that will
|
||||
print the device physical offset and the adjusted value for */sys/power/resume_offset*.
|
||||
Note that the value is divided by page size, ie. it's not the offset itself.
|
||||
Note that the value is divided by page size, i.e. it's not the offset itself.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -106,7 +106,7 @@ For scripting and convenience the option *-r* will print just the offset:
|
||||
# btrfs inspect-internal map-swapfile -r swapfile
|
||||
198122980
|
||||
|
||||
The command *map-swapfile* also verifies all the requirements, ie. no holes,
|
||||
The command *map-swapfile* also verifies all the requirements, i.e. no holes,
|
||||
single device, etc.
|
||||
|
||||
|
||||
@ -114,7 +114,7 @@ Troubleshooting
|
||||
---------------
|
||||
|
||||
If the swapfile activation fails please verify that you followed all the steps
|
||||
above or check the system log (eg. ``dmesg`` or ``journalctl``) for more
|
||||
above or check the system log (e.g. ``dmesg`` or ``journalctl``) for more
|
||||
information.
|
||||
|
||||
Notably, the *swapon* utility exits with a message that does not say what
|
||||
|
||||
@ -90,7 +90,7 @@ we're going to lose 50GiB of the second device for obvious reasons.
|
||||
|
||||
$ btrfs balance start -dconvert=raid1 /mnt
|
||||
|
||||
The balance process needs some workspace (ie. a free device space without any
|
||||
The balance process needs some workspace (i.e. a free device space without any
|
||||
data or metadata block groups) so the command could fail if there's too much
|
||||
data or the block groups occupy the whole first device.
|
||||
|
||||
|
||||
@ -31,7 +31,7 @@ Incompatible features
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The main constraint of the zoned devices is lack of in-place update of the data.
|
||||
This is inherently incompatibile with some features:
|
||||
This is inherently incompatible with some features:
|
||||
|
||||
* nodatacow - overwrite in-place, cannot create such files
|
||||
* fallocate - preallocating space for in-place first write
|
||||
@ -61,6 +61,6 @@ offsets of both zones and determine the last written version.
|
||||
The amount of space reserved for super block depends on the zone size. The
|
||||
secondary and tertiary copies are at distant offsets as the capacity of the
|
||||
devices is expected to be large, tens of terabytes. Maximum zone size supported
|
||||
is 8GiB, which would mean that eg. offset 0-16GiB would be reserved just for
|
||||
is 8GiB, which would mean that e.g. offset 0-16GiB would be reserved just for
|
||||
the super block on a hypothetical device of that zone size. This is wasteful
|
||||
but required to guarantee crash safety.
|
||||
|
||||
@ -7,7 +7,7 @@ filesystem (send side). The stream is currently used in two ways: to generate a
|
||||
stream representing a standalone subvolume (full mode) or a difference between
|
||||
two snapshots of the same subvolume (incremental mode). The stream can be
|
||||
generated using a set of other subvolumes to look for extent references that
|
||||
could lead to a more efficient stream by transfering only the references and
|
||||
could lead to a more efficient stream by transferring only the references and
|
||||
not full data.
|
||||
|
||||
The stream format is abstracted from on-disk structures (though it may share
|
||||
@ -32,7 +32,7 @@ Stream structure
|
||||
----------------
|
||||
|
||||
The stream starts with a descriptor bytes ``btrfs-stream`` followed by version
|
||||
stored as litte endian u32. Then the sequence of commands starts. The expected
|
||||
stored as little endian u32. Then the sequence of commands starts. The expected
|
||||
start is a subvolume or snapshot followed by commands to change the data.
|
||||
|
||||
Command structure
|
||||
@ -128,7 +128,7 @@ Raw data type is processed in a different way in protocol version 1 and 2. In 1
|
||||
the maximum size of the TLV is 64KiB as the size is stored in u16. This is not
|
||||
sufficient for encoded write (ENCODED_WRITE) command. In 2 the data length is
|
||||
up to 4GiB (using the type u32) but the TLV must be last and the actual
|
||||
length is calculated as the delta between the whole command and the TLV (ie.
|
||||
length is calculated as the delta between the whole command and the TLV (i.e.
|
||||
ignoring the TLV header length).
|
||||
|
||||
Stream version 1
|
||||
@ -265,7 +265,7 @@ Write file data to a given file offset.
|
||||
|
||||
- string path - relative file path
|
||||
- u64 - file offset where to write data
|
||||
- data - raw file data (varaible length)
|
||||
- data - raw file data (variable length)
|
||||
|
||||
BTRFS_SEND_C_CLONE (16)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@ -37,7 +37,7 @@ There are two possible exit codes returned:
|
||||
No error
|
||||
|
||||
8
|
||||
Operational error, eg. device does not exist
|
||||
Operational error, e.g. device does not exist
|
||||
|
||||
FILES
|
||||
-----
|
||||
|
||||
@ -283,7 +283,7 @@ zoned
|
||||
RUNTIME FEATURES
|
||||
----------------
|
||||
|
||||
Features that are typically enabled on a mounted filesystem, eg. by a mount
|
||||
Features that are typically enabled on a mounted filesystem, e.g. 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.
|
||||
@ -390,8 +390,8 @@ PROFILE LAYOUT
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
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,
|
||||
metadata blocks A, B, C, D, with possible stripes e.g. A1, A2 that would be
|
||||
logically A, etc. For parity profiles PA and QA are parity and syndrome,
|
||||
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
|
||||
|
||||
@ -90,7 +90,7 @@ Deletion still works.
|
||||
Balance does not have enough workspace
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Relocation of block groups requires a temporary work space, ie. area on the
|
||||
Relocation of block groups requires a temporary work space, i.e. area on the
|
||||
device that's available for the filesystem but without any other existing block
|
||||
groups. Before balance starts a check is performed to verify the requested
|
||||
action is possible. If not, ENOSPC is returned.
|
||||
@ -161,8 +161,8 @@ Stale signature on device
|
||||
Related problem regarding partitioned and unpartitioned device: *Long time ago
|
||||
I created btrfs on /dev/sda. After some changes btrfs moved to /dev/sda1.*
|
||||
|
||||
Use ``wipefs -o 0x10040`` (ie. with the offset of the btrfs signature), it
|
||||
won't touch the parition table.
|
||||
Use ``wipefs -o 0x10040`` (i.e. with the offset of the btrfs signature), it
|
||||
won't touch the partition table.
|
||||
|
||||
Manual deletion of super block signature
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@ -190,7 +190,7 @@ Generic errors, errno
|
||||
---------------------
|
||||
|
||||
Note there's a established text message for the errors, though they are used in
|
||||
a broader sense (eg. error mentions a file but it can be relevant for another
|
||||
a broader sense (e.g. error mentions a file but it can be relevant for another
|
||||
structure). The title of each section uses the nonstandard meaning that is
|
||||
perhaps more suitable for a filesystem.
|
||||
|
||||
@ -198,7 +198,7 @@ ENOENT (No such entry)
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Common error "no such entry", in general it may mean that some structure hasn't
|
||||
been found, eg. an entry in some in-memory tree. This becomes a critical
|
||||
been found, e.g. an entry in some in-memory tree. This becomes a critical
|
||||
problem when the entry is expected to exist because of consistency of the
|
||||
structures.
|
||||
|
||||
@ -209,14 +209,14 @@ Memory allocation error. In many cases the error is recoverable and the
|
||||
operation restartable after it's reported to userspace. In critical contexts,
|
||||
like when a transaction needs to be committed, the error is not recoverable and
|
||||
leads to flipping the filesystem to read-only. Such cases are rare under normal
|
||||
conditions. Memory can be artificially limited eg. by cgroups, which may
|
||||
conditions. Memory can be artificially limited e.g. by cgroups, which may
|
||||
trigger the condition, which is useful for testing but any real workload should
|
||||
have resources scaled accordingly.
|
||||
|
||||
EINVAL (Invalid argument)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This is typically returned from ioctl when a parameter is invalid, ie. unexpected
|
||||
This is typically returned from ioctl when a parameter is invalid, i.e. unexpected
|
||||
range, a bit flag not recognized, or a combination of input parameters that
|
||||
does not make sense. Errors are typically recoverable.
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user