btrfs-progs: docs: fix typos

Namely change eg. to e.g. and ie. to i.e.

Signed-off-by: David Sterba <dsterba@suse.com>

Documentation/Auto-repair.rst

@@ -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

Documentation/CmdLineConventions

@@ -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
 

Documentation/Deduplication.rst

@@ -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*

Documentation/Defragmentation.rst

@@ -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.
 

Documentation/DocConventions.rst

@@ -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>

Documentation/Feature-by-version.rst

@@ -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*

Documentation/Glossary.rst

@@ -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

Documentation/Inline-files.rst

@@ -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

Documentation/Send-receive.rst

@@ -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

Documentation/Source-repositories.rst

@@ -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*).
+* queue with patches for current release cycle (the name has the version, e.g. *for-4.15* or *misc-4.15*).
-* topic branches, eg. from a patchset picked from mailinglist
+* topic branches, e.g. from a patchset picked from mailing list
-* snapshots of *for-next*, that contain all of the above (eg. for-next-20200512)
+* 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
+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 mailinglist or for convenience.
+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

Documentation/Subpage.rst

@@ -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

Documentation/Tree-checker.rst

@@ -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
+and what items are stored there, i.e. there's no extensive or broad check done
-eg. against other data structures in other b-tree nodes. This still provides
+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*.

Documentation/btrfs-balance.rst

@@ -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:

Documentation/btrfs-check.rst

@@ -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

Documentation/btrfs-device.rst

@@ -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

Documentation/btrfs-filesystem.rst

@@ -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::

Documentation/btrfs-image.rst

@@ -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

Documentation/btrfs-inspect-internal.rst

@@ -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
+                * the C source definition, e.g. BTRFS_ROOT_TREE_OBJECTID
-                * short forms without BTRFS\_ prefix, without _TREE and _OBJECTID suffix, eg. ROOT_TREE, ROOT
+                * short forms without BTRFS\_ prefix, without _TREE and _OBJECTID suffix, e.g. ROOT_TREE, ROOT
-                * convenience aliases, eg. DEVICE for the DEV tree, CHECKSUM for CSUM
+                * 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

Documentation/btrfs-man5.rst

@@ -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
+reporting is inaccurate, e.g. **df**, **btrfs filesystem df** or **btrfs filesystem
-usage**. When there's only a one profile per block group type (eg. raid5 for data)
+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

Documentation/btrfs-property.rst

@@ -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::

Documentation/btrfs-qgroup.rst

@@ -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

Documentation/btrfs-receive.rst

@@ -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

Documentation/btrfs-rescue.rst

@@ -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

Documentation/btrfs-restore.rst

@@ -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

Documentation/btrfs-select-super.rst

@@ -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.
 

Documentation/ch-balance-filters.rst

@@ -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

Documentation/ch-balance-intro.rst

@@ -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.
 

Documentation/ch-compression.rst

@@ -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

Documentation/ch-convert-intro.rst

@@ -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
+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 filessytem prior
+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:

Documentation/ch-fs-limits.rst

@@ -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.
 

Documentation/ch-hardware-considerations.rst

@@ -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.
 

Documentation/ch-mount-options.rst

@@ -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).
 
-
-

Documentation/ch-quota-intro.rst

@@ -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.
 

Documentation/ch-seeding-device.rst

@@ -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*
 

Documentation/ch-subvolume-intro.rst

@@ -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
+that stores data to be preserved across rollbacks is it's own subvolume. This
-could be eg. ``/var``. Further more-fine grained partitioning could be done, eg.
+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.

Documentation/ch-swapfile.rst

@@ -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 preallocated (i.e. no holes)
-* swapfile - must be nodatacow (ie. also nodatasum, no compression)
+* 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

Documentation/ch-volume-management-intro.rst

@@ -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.
 

Documentation/ch-zoned-intro.rst

@@ -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.

Documentation/dev-send-stream.rst

@@ -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)
 ^^^^^^^^^^^^^^^^^^^^^^^

Documentation/fsck.btrfs.rst

@@ -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
 -----

Documentation/mkfs.btrfs.rst

@@ -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
+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 syndrom,
+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

Documentation/trouble-index.rst

@@ -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
+Use ``wipefs -o 0x10040`` (i.e. with the offset of the btrfs signature), it
-won't touch the parition table.
+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.