diff --git a/Documentation/Auto-repair.rst b/Documentation/Auto-repair.rst index 31760d09..303f567f 100644 --- a/Documentation/Auto-repair.rst +++ b/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 diff --git a/Documentation/CmdLineConventions b/Documentation/CmdLineConventions index 409ac731..df6bf42f 100644 --- a/Documentation/CmdLineConventions +++ b/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 diff --git a/Documentation/Deduplication.rst b/Documentation/Deduplication.rst index 37232f48..ba5aacc5 100644 --- a/Documentation/Deduplication.rst +++ b/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* diff --git a/Documentation/Defragmentation.rst b/Documentation/Defragmentation.rst index 318ce075..e96f3d9e 100644 --- a/Documentation/Defragmentation.rst +++ b/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. diff --git a/Documentation/DocConventions.rst b/Documentation/DocConventions.rst index a3996afd..c5b4117b 100644 --- a/Documentation/DocConventions.rst +++ b/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 diff --git a/Documentation/Feature-by-version.rst b/Documentation/Feature-by-version.rst index b864e1e3..1502d76c 100644 --- a/Documentation/Feature-by-version.rst +++ b/Documentation/Feature-by-version.rst @@ -212,7 +212,7 @@ features see [[Status]] page. ref-verify, 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* diff --git a/Documentation/Glossary.rst b/Documentation/Glossary.rst index 3d897109..b5a764bd 100644 --- a/Documentation/Glossary.rst +++ b/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 diff --git a/Documentation/Inline-files.rst b/Documentation/Inline-files.rst index fdd86073..6424245b 100644 --- a/Documentation/Inline-files.rst +++ b/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 diff --git a/Documentation/Send-receive.rst b/Documentation/Send-receive.rst index a965ff6a..1d93807a 100644 --- a/Documentation/Send-receive.rst +++ b/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 diff --git a/Documentation/Source-repositories.rst b/Documentation/Source-repositories.rst index 25499480..e4d8c817 100644 --- a/Documentation/Source-repositories.rst +++ b/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*). -* 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 diff --git a/Documentation/Subpage.rst b/Documentation/Subpage.rst index 35229665..21a495d5 100644 --- a/Documentation/Subpage.rst +++ b/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 diff --git a/Documentation/Tree-checker.rst b/Documentation/Tree-checker.rst index 2f6449d0..68df6fdf 100644 --- a/Documentation/Tree-checker.rst +++ b/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 -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*. diff --git a/Documentation/btrfs-balance.rst b/Documentation/btrfs-balance.rst index dd31bbf3..ad45ff54 100644 --- a/Documentation/btrfs-balance.rst +++ b/Documentation/btrfs-balance.rst @@ -16,7 +16,7 @@ SUBCOMMAND cancel 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 resume 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] @@ -38,7 +38,7 @@ start [options] .. 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] 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: diff --git a/Documentation/btrfs-check.rst b/Documentation/btrfs-check.rst index 7d5a5f86..c7ae11c7 100644 --- a/Documentation/btrfs-check.rst +++ b/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 diff --git a/Documentation/btrfs-device.rst b/Documentation/btrfs-device.rst index 0a16a279..818048b0 100644 --- a/Documentation/btrfs-device.rst +++ b/Documentation/btrfs-device.rst @@ -25,7 +25,7 @@ add [-Kf] [...] 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] [...]:: * *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 diff --git a/Documentation/btrfs-filesystem.rst b/Documentation/btrfs-filesystem.rst index 4520a187..24d7157d 100644 --- a/Documentation/btrfs-filesystem.rst +++ b/Documentation/btrfs-filesystem.rst @@ -41,11 +41,11 @@ df [options] 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] | [|...] 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 [kKmMgGtTpPeE] defragmentation will start from the given offset, default is beginning of a file @@ -332,11 +332,11 @@ usage [options] [...] * *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] [...] 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:: diff --git a/Documentation/btrfs-image.rst b/Documentation/btrfs-image.rst index edc252a3..682ea5e7 100644 --- a/Documentation/btrfs-image.rst +++ b/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 diff --git a/Documentation/btrfs-inspect-internal.rst b/Documentation/btrfs-inspect-internal.rst index 4a0f3698..3f163456 100644 --- a/Documentation/btrfs-inspect-internal.rst +++ b/Documentation/btrfs-inspect-internal.rst @@ -80,9 +80,9 @@ dump-tree [options] [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...] 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] (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] rootid 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 diff --git a/Documentation/btrfs-man5.rst b/Documentation/btrfs-man5.rst index 5631f908..3a4feeb6 100644 --- a/Documentation/btrfs-man5.rst +++ b/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 -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 diff --git a/Documentation/btrfs-property.rst b/Documentation/btrfs-property.rst index 309d7047..e2cb2e6b 100644 --- a/Documentation/btrfs-property.rst +++ b/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:: diff --git a/Documentation/btrfs-qgroup.rst b/Documentation/btrfs-qgroup.rst index f4c59b71..ab1c6347 100644 --- a/Documentation/btrfs-qgroup.rst +++ b/Documentation/btrfs-qgroup.rst @@ -156,7 +156,7 @@ show [options] 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 diff --git a/Documentation/btrfs-receive.rst b/Documentation/btrfs-receive.rst index 27b687e4..7ecb23e2 100644 --- a/Documentation/btrfs-receive.rst +++ b/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 diff --git a/Documentation/btrfs-rescue.rst b/Documentation/btrfs-rescue.rst index 2d6b25c7..8b43c50b 100644 --- a/Documentation/btrfs-rescue.rst +++ b/Documentation/btrfs-rescue.rst @@ -74,7 +74,7 @@ zero-log 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 diff --git a/Documentation/btrfs-restore.rst b/Documentation/btrfs-restore.rst index 73668af2..7ef9873b 100644 --- a/Documentation/btrfs-restore.rst +++ b/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 use *bytenr* to read the root tree diff --git a/Documentation/btrfs-select-super.rst b/Documentation/btrfs-select-super.rst index ff3ae3ad..6f4990e2 100644 --- a/Documentation/btrfs-select-super.rst +++ b/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. diff --git a/Documentation/ch-balance-filters.rst b/Documentation/ch-balance-filters.rst index 5754a262..3341a01b 100644 --- a/Documentation/ch-balance-filters.rst +++ b/Documentation/ch-balance-filters.rst @@ -62,7 +62,7 @@ limit=, limit= stripes= 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 diff --git a/Documentation/ch-balance-intro.rst b/Documentation/ch-balance-intro.rst index 783d3680..6e053de6 100644 --- a/Documentation/ch-balance-intro.rst +++ b/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. diff --git a/Documentation/ch-compression.rst b/Documentation/ch-compression.rst index ada63976..1cd6be43 100644 --- a/Documentation/ch-compression.rst +++ b/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 diff --git a/Documentation/ch-convert-intro.rst b/Documentation/ch-convert-intro.rst index 7439bf6a..a4cbe03b 100644 --- a/Documentation/ch-convert-intro.rst +++ b/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 -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: diff --git a/Documentation/ch-fs-limits.rst b/Documentation/ch-fs-limits.rst index 51953078..976366b7 100644 --- a/Documentation/ch-fs-limits.rst +++ b/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. diff --git a/Documentation/ch-hardware-considerations.rst b/Documentation/ch-hardware-considerations.rst index 993b02d9..76210edd 100644 --- a/Documentation/ch-hardware-considerations.rst +++ b/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. diff --git a/Documentation/ch-mount-options.rst b/Documentation/ch-mount-options.rst index cbe5058c..f7dfbc1a 100644 --- a/Documentation/ch-mount-options.rst +++ b/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= 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= 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). - - diff --git a/Documentation/ch-quota-intro.rst b/Documentation/ch-quota-intro.rst index a3b9d3b2..161bed76 100644 --- a/Documentation/ch-quota-intro.rst +++ b/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. diff --git a/Documentation/ch-seeding-device.rst b/Documentation/ch-seeding-device.rst index 2470af82..6ab747b1 100644 --- a/Documentation/ch-seeding-device.rst +++ b/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* diff --git a/Documentation/ch-subvolume-intro.rst b/Documentation/ch-subvolume-intro.rst index 97269c64..1debdadc 100644 --- a/Documentation/ch-subvolume-intro.rst +++ b/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 -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. diff --git a/Documentation/ch-swapfile.rst b/Documentation/ch-swapfile.rst index 551fc391..c8e55b22 100644 --- a/Documentation/ch-swapfile.rst +++ b/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 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 diff --git a/Documentation/ch-volume-management-intro.rst b/Documentation/ch-volume-management-intro.rst index e0e16445..3cb24a80 100644 --- a/Documentation/ch-volume-management-intro.rst +++ b/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. diff --git a/Documentation/ch-zoned-intro.rst b/Documentation/ch-zoned-intro.rst index fc8bed49..c522086b 100644 --- a/Documentation/ch-zoned-intro.rst +++ b/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. diff --git a/Documentation/dev-send-stream.rst b/Documentation/dev-send-stream.rst index 6ac3878c..e8dedec9 100644 --- a/Documentation/dev-send-stream.rst +++ b/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) ^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/fsck.btrfs.rst b/Documentation/fsck.btrfs.rst index 6d7c6efc..250ce89c 100644 --- a/Documentation/fsck.btrfs.rst +++ b/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 ----- diff --git a/Documentation/mkfs.btrfs.rst b/Documentation/mkfs.btrfs.rst index 9056bd6c..bb795ad9 100644 --- a/Documentation/mkfs.btrfs.rst +++ b/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 -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 diff --git a/Documentation/trouble-index.rst b/Documentation/trouble-index.rst index 42d31d35..5a51f070 100644 --- a/Documentation/trouble-index.rst +++ b/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 -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.