Hi Nikolay, Thank you for nit-picking, I'm definitely not above reproach and often make errors--especially in my own writing! Reply follows below.
On Fri, Mar 16, 2018 at 10:00:34AM +0200, Nikolay Borisov wrote:
>
>
> On 16.03.2018 02:39, Nicholas D Steeves wrote:
> > Signed-off-by: Nicholas D Steeves <nstee...@gmail.com>
>
>
> All look fine except one nit, see below.
>
> > ---
> > Documentation/btrfs-balance.asciidoc | 2 +-
> > Documentation/btrfs-check.asciidoc | 2 +-
> > Documentation/btrfs-man5.asciidoc | 8 ++++----
> > cmds-subvolume.c | 2 +-
> > 4 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/btrfs-balance.asciidoc
> > b/Documentation/btrfs-balance.asciidoc
> > index 7017bed7..536243bc 100644
> > --- a/Documentation/btrfs-balance.asciidoc
> > +++ b/Documentation/btrfs-balance.asciidoc
> > @@ -204,7 +204,7 @@ The way balance operates, it usually needs to
> > temporarily create a new block
> > group and move the old data there, before the old block group can be
> > removed.
> > For that it needs the work space, otherwise it fails for ENOSPC reasons.
> > This is not the same ENOSPC as if the free space is exhausted. This refers
> > to
> > -the space on the level of block groups, which are bigger parts of the
> > filesytem
> > +the space on the level of block groups, which are bigger parts of the
> > filesystem
> > that contain many file extents.
> >
> > The free work space can be calculated from the output of the *btrfs
> > filesystem show*
> > diff --git a/Documentation/btrfs-check.asciidoc
> > b/Documentation/btrfs-check.asciidoc
> > index cc76d846..b963eae5 100644
> > --- a/Documentation/btrfs-check.asciidoc
> > +++ b/Documentation/btrfs-check.asciidoc
> > @@ -122,7 +122,7 @@ NOTE: 'lowmem' mode does not work with '--repair' yet,
> > and is still considered
> > experimental.
> >
> > --force::
> > -allow to work on a mounted filesystem. Note that this should work fine on a
> > +allow work on a mounted filesystem. Note that this should work fine on a
> Shouldn't we use the continuous aspect of the verb here, i.e.
> s/work/working ? (I'm not a native speaker so take it with a grain of salt)
I'm not sure, but if the format is:
"[implied subject] verb, other stuff", then:
[The --force argument] allows work on a mounted filesystem. [1]
or alternatively:
allows operations on a mounted filesystem. [2]
or
allows operations to work on a mounted filesystem. [3]
but if we're in imperative/declarative then:
[Allow] Work on a mounted filesystem. [4]
and not
[Allow] Working on a mounted filesystem. [5]
Because "Working on a mounted filesystem" [5] is a sentence fragment
(also see related discussing at [6] below). I chose [4] because it
required the fewest changes ;-)
In "Allow work on a mounted filesystem" [4]
"Allow" is the verb and "work" is the object, but if "Allow" is
dropped and the phrase becomes "work on a mounted filesystem" then
"work" becomes the verb, using its identically spelled verb form. The
following is also grammatically correct if the rule is:
"(argument_name functioning as imperative verb), [participial phrase]"
eg: --force, allowing work on a mounted filesystem. [6]
but IIRC [6] is considered poor style for Science writing and
documentation--not to mention it also might make translation
difficult, and finally it breaks whenever --argument cannot function
as a verb. It's also tricky to analyse ing-verbs to tell if they're
gerund or participial when dealing with the truncated grammatical
context that is conventional in manpages.
As ever, I might be wrong, but this is my reasoning :-)
Cheers,
Nicholas
signature.asc
Description: PGP signature
