On 27.11.18 г. 15:56 ч., Andrea Gelmini wrote: > Signed-off-by: Andrea Gelmini <andrea.gelmini@xxxxxxxxx> Reviewed-by: Nikolay Borisov <nborisov@xxxxxxxx> > --- > Documentation/DocConventions | 4 ++-- > Documentation/ReleaseChecklist | 4 ++-- > Documentation/btrfs-man5.asciidoc | 8 ++++---- > Documentation/btrfs-property.asciidoc | 2 +- > Documentation/btrfs-qgroup.asciidoc | 4 ++-- > Documentation/mkfs.btrfs.asciidoc | 2 +- > 6 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/Documentation/DocConventions b/Documentation/DocConventions > index e84ed7a..969209c 100644 > --- a/Documentation/DocConventions > +++ b/Documentation/DocConventions > @@ -23,7 +23,7 @@ Quotation in subcommands: > - command reference: bold *btrfs fi show* > - section references: italics 'EXAMPLES' > > -- argument name in option desciption: caps in angle brackets <NAME> > +- argument name in option description: caps in angle brackets <NAME> > - reference in help text: caps NAME > also possible: caps italics 'NAME' > > @@ -34,6 +34,6 @@ Quotation in subcommands: > - optional parameter with argument: [-p <path>] > > > -Refrences: > +References: > - full asciidoc syntax: http://asciidoc.org/userguide.html > - cheatsheet: http://powerman.name/doc/asciidoc > diff --git a/Documentation/ReleaseChecklist b/Documentation/ReleaseChecklist > index d8bf50c..ebe251d 100644 > --- a/Documentation/ReleaseChecklist > +++ b/Documentation/ReleaseChecklist > @@ -4,7 +4,7 @@ Release checklist > Last code touches: > > * make the code ready, collect patches queued for the release > -* look to mailinglist for any relevant last-minute fixes > +* look to mailing list for any relevant last-minute fixes > > Pre-checks: > > @@ -31,7 +31,7 @@ Release: > > Post-release: > > -* write and send announcement mail to mailinglist > +* write and send announcement mail to mailing list > * update wiki://Main_page#News > * update wiki://Changelog#btrfs-progs > * update title on IRC > diff --git a/Documentation/btrfs-man5.asciidoc b/Documentation/btrfs-man5.asciidoc > index 448710a..4a269e2 100644 > --- a/Documentation/btrfs-man5.asciidoc > +++ b/Documentation/btrfs-man5.asciidoc > @@ -156,7 +156,7 @@ under 'nodatacow' are also set the NOCOW file attribute (see `chattr`(1)). > NOTE: If 'nodatacow' or 'nodatasum' are enabled, compression is disabled. > + > Updates in-place improve performance for workloads that do frequent overwrites, > -at the cost of potential partial writes, in case the write is interruted > +at the cost of potential partial writes, in case the write is interrupted > (system crash, device failure). > > *datasum*:: > @@ -171,7 +171,7 @@ corresponding file attribute (see `chattr`(1)). > NOTE: If 'nodatacow' or 'nodatasum' are enabled, compression is disabled. > + > There is a slight performance gain when checksums are turned off, the > -correspoinding metadata blocks holding the checksums do not need to updated. > +corresponding metadata blocks holding the checksums do not need to be updated. > The cost of checksumming of the blocks in memory is much lower than the IO, > modern CPUs feature hardware support of the checksumming algorithm. > > @@ -185,7 +185,7 @@ 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 > filesystems with mixed RAID profiles for data and metadata, even if the > -device number constraints would not be satisfied for some of the prifles. > +device number constraints would not be satisfied for some of the profiles. > + > Example: metadata -- raid1, data -- single, devices -- /dev/sda, /dev/sdb > + > @@ -649,7 +649,7 @@ inherent limit of btrfs is 2^64^ (16 EiB) but the linux VFS limit is 2^63^ (8 Ei > > maximum number of subvolumes:: > 2^64^ but depends on the available metadata space, the space consumed by all > -subvolume metadata includes bookeeping of the shared extents can be large (MiB, > +subvolume metadata includes bookkeeping of the shared extents can be large (MiB, > GiB) > > maximum number of hardlinks of a file in a directory:: > diff --git a/Documentation/btrfs-property.asciidoc b/Documentation/btrfs-property.asciidoc > index b562717..4bad88b 100644 > --- a/Documentation/btrfs-property.asciidoc > +++ b/Documentation/btrfs-property.asciidoc > @@ -34,7 +34,7 @@ specify what type of object you meant. This is only needed when a > property could be set for more then one object type. > + > Possible types are 's[ubvol]', 'f[ilesystem]', 'i[node]' and 'd[evice]', where > -the first lettes is a shortcut. > +the first letter is a shortcut. > + > Set the name of property by 'name'. If no 'name' is specified, > all properties for the given object are printed. 'name' is one of > diff --git a/Documentation/btrfs-qgroup.asciidoc b/Documentation/btrfs-qgroup.asciidoc > index dff0867..dc4c93b 100644 > --- a/Documentation/btrfs-qgroup.asciidoc > +++ b/Documentation/btrfs-qgroup.asciidoc > @@ -52,7 +52,7 @@ assignment would lead to quota inconsistency. See 'QUOTA RESCAN' for more > information. > --no-rescan:::: > Explicitly ask not to do a rescan, even if the assignment will make the quotas > -inconsitent. This may be useful for repeated calls where the rescan would add > +inconsistent. This may be useful for repeated calls where the rescan would add > unnecessary overhead. > > *create* <qgroupid> <path>:: > @@ -140,7 +140,7 @@ force sync of the filesystem identified by <path> before getting information. > > 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/mkfs.btrfs.asciidoc b/Documentation/mkfs.btrfs.asciidoc > index 2a1c359..84e9cc0 100644 > --- a/Documentation/mkfs.btrfs.asciidoc > +++ b/Documentation/mkfs.btrfs.asciidoc > @@ -314,7 +314,7 @@ layer between the logical and physical view of the device. The data lifetime > may be affected by frequent plugging. The memory cells could get damaged, > hopefully not destroying both copies of particular data in case of DUP. > > -The wear levelling techniques can also lead to reduced redundancy, even if the > +The wear leveling techniques can also lead to reduced redundancy, even if the > device does not do any deduplication. The controllers may put data written in > a short timespan into the same physical storage unit (cell, block etc). In case > this unit dies, both copies are lost. BTRFS does not add any artificial delay >
