btrfs-progs: small fixes/cleanup in Documentation
diff mbox series

Message ID 20191017045006.130378-1-merlin.buege@tuhh.de
State New
Headers show
Series
  • btrfs-progs: small fixes/cleanup in Documentation
Related show

Commit Message

Merlin Büge Oct. 17, 2019, 4:50 a.m. UTC
The removed paragraph in btrfs-man5.asciidoc says the same as the
previous one.
---
 Documentation/btrfs-man5.asciidoc |  6 ------
 Documentation/mkfs.btrfs.asciidoc | 10 +++++-----
 2 files changed, 5 insertions(+), 11 deletions(-)

Comments

Nikolay Borisov Oct. 17, 2019, 6:29 a.m. UTC | #1
On 17.10.19 г. 7:50 ч., Merlin Büge  wrote:
> The removed paragraph in btrfs-man5.asciidoc says the same as the
> previous one.

This patch cannot be applied without an SOB line. Otherwise the changes
look good.

> ---
>  Documentation/btrfs-man5.asciidoc |  6 ------
>  Documentation/mkfs.btrfs.asciidoc | 10 +++++-----
>  2 files changed, 5 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/btrfs-man5.asciidoc b/Documentation/btrfs-man5.asciidoc
> index 6a1a04b7..87ed5496 100644
> --- a/Documentation/btrfs-man5.asciidoc
> +++ b/Documentation/btrfs-man5.asciidoc
> @@ -224,12 +224,6 @@ during a period of low system activity will prevent latent interference with
>  the performance of other operations. Also, a device may ignore the TRIM command
>  if the range is too small, so running a batch discard has a greater probability
>  of actually discarding the blocks.
> -+
> -If discarding is not necessary to be done at the block freeing time, there's
> -`fstrim`(8) tool that lets the filesystem discard all free blocks in a batch,
> -possibly not much interfering with other operations. Also, the device may
> -ignore the TRIM command if the range is too small, so running the batch discard
> -can actually discard the blocks.
>  
>  *enospc_debug*::
>  *noenospc_debug*::
> diff --git a/Documentation/mkfs.btrfs.asciidoc b/Documentation/mkfs.btrfs.asciidoc
> index 2a1c3592..ef3eb13f 100644
> --- a/Documentation/mkfs.btrfs.asciidoc
> +++ b/Documentation/mkfs.btrfs.asciidoc
> @@ -27,17 +27,17 @@ mkfs.btrfs uses the entire device space for the filesystem.
>  
>  *-d|--data <profile>*::
>  Specify the profile for the data block groups.  Valid values are 'raid0',
> -'raid1', 'raid5', 'raid6', 'raid10' or 'single' or dup (case does not matter).
> +'raid1', 'raid5', 'raid6', 'raid10' or 'single' or 'dup' (case does not matter).
>  +
> -See 'DUP PROFILES ON A SINGLE DEVICE' for more.
> +See 'DUP PROFILES ON A SINGLE DEVICE' for more details.
>  
>  *-m|--metadata <profile>*::
>  Specify the profile for the metadata block groups.
>  Valid values are 'raid0', 'raid1', 'raid5', 'raid6', 'raid10', 'single' or
> -'dup', (case does not matter).
> +'dup' (case does not matter).
>  +
> -A single device filesystem will default to 'DUP', unless a SSD is detected. Then
> -it will default to 'single'. The detection is based on the value of
> +A single device filesystem will default to 'DUP', unless an SSD is detected, in which
> +case it will default to 'single'. The detection is based on the value of
>  `/sys/block/DEV/queue/rotational`, where 'DEV' is the short name of the device.
>  +
>  Note that the rotational status can be arbitrarily set by the underlying block
>
David Sterba Oct. 17, 2019, 11:18 a.m. UTC | #2
On Thu, Oct 17, 2019 at 09:29:43AM +0300, Nikolay Borisov wrote:
> 
> 
> On 17.10.19 г. 7:50 ч., Merlin Büge  wrote:
> > The removed paragraph in btrfs-man5.asciidoc says the same as the
> > previous one.
> 
> This patch cannot be applied without an SOB line. Otherwise the changes
> look good.

Well, for documentation patches and for progs it's not that strict and
I've applied many drive-by patches. My sign-off will be there and the
original author is usually mentioned as Author:, so the credit is
recorded.
Merlin Büge Oct. 17, 2019, 2:47 p.m. UTC | #3
On Thu, 17 Oct 2019 13:18:05 +0200
David Sterba <dsterba@suse.cz> wrote:

> Well, for documentation patches and for progs it's not that strict and
> I've applied many drive-by patches. My sign-off will be there and the
> original author is usually mentioned as Author:, so the credit is
> recorded.

I'm fine with that.

Sorry, I'm not yet really familiar with the email driven patch workflow
(actually it's my first patch via email). I will include a SOB line
next time. If I should resend this patch with one, please tell me!

Q: How would I go about updating the patch? Just completely resend it
to the mailing list from scratch so a new thread gets created, or
replying to the existing one?

@David: Sorry for double posting.

Thanks.
David Sterba Oct. 18, 2019, 12:07 p.m. UTC | #4
On Thu, Oct 17, 2019 at 04:47:31PM +0200, Merlin Büge wrote:
> On Thu, 17 Oct 2019 13:18:05 +0200
> David Sterba <dsterba@suse.cz> wrote:
> 
> > Well, for documentation patches and for progs it's not that strict and
> > I've applied many drive-by patches. My sign-off will be there and the
> > original author is usually mentioned as Author:, so the credit is
> > recorded.
> 
> I'm fine with that.
> 
> Sorry, I'm not yet really familiar with the email driven patch workflow
> (actually it's my first patch via email). I will include a SOB line
> next time. If I should resend this patch with one, please tell me!

No need to resend, getting documentation updates should not pose any
barrier as they can be sent by anyone who found something to fix and
insisting on the formalities (that are otherwise a good thing for code)
would probably discourage people.

> Q: How would I go about updating the patch? Just completely resend it
> to the mailing list from scratch so a new thread gets created, or
> replying to the existing one?

Replying to the same would be better in this case. If you don't have
more updates to the docs resending is not necessary, unless you want to
exercise sending patches by mail.
Merlin Büge Oct. 18, 2019, 2:56 p.m. UTC | #5
On Fri, 18 Oct 2019 14:07:45 +0200
David Sterba <dsterba@suse.cz> wrote:
...
> > Q: How would I go about updating the patch? Just completely resend it
> > to the mailing list from scratch so a new thread gets created, or
> > replying to the existing one?  
> 
> Replying to the same would be better in this case. If you don't have
> more updates to the docs resending is not necessary, unless you want to
> exercise sending patches by mail.

Thanks for your explanation.

Patch
diff mbox series

diff --git a/Documentation/btrfs-man5.asciidoc b/Documentation/btrfs-man5.asciidoc
index 6a1a04b7..87ed5496 100644
--- a/Documentation/btrfs-man5.asciidoc
+++ b/Documentation/btrfs-man5.asciidoc
@@ -224,12 +224,6 @@  during a period of low system activity will prevent latent interference with
 the performance of other operations. Also, a device may ignore the TRIM command
 if the range is too small, so running a batch discard has a greater probability
 of actually discarding the blocks.
-+
-If discarding is not necessary to be done at the block freeing time, there's
-`fstrim`(8) tool that lets the filesystem discard all free blocks in a batch,
-possibly not much interfering with other operations. Also, the device may
-ignore the TRIM command if the range is too small, so running the batch discard
-can actually discard the blocks.
 
 *enospc_debug*::
 *noenospc_debug*::
diff --git a/Documentation/mkfs.btrfs.asciidoc b/Documentation/mkfs.btrfs.asciidoc
index 2a1c3592..ef3eb13f 100644
--- a/Documentation/mkfs.btrfs.asciidoc
+++ b/Documentation/mkfs.btrfs.asciidoc
@@ -27,17 +27,17 @@  mkfs.btrfs uses the entire device space for the filesystem.
 
 *-d|--data <profile>*::
 Specify the profile for the data block groups.  Valid values are 'raid0',
-'raid1', 'raid5', 'raid6', 'raid10' or 'single' or dup (case does not matter).
+'raid1', 'raid5', 'raid6', 'raid10' or 'single' or 'dup' (case does not matter).
 +
-See 'DUP PROFILES ON A SINGLE DEVICE' for more.
+See 'DUP PROFILES ON A SINGLE DEVICE' for more details.
 
 *-m|--metadata <profile>*::
 Specify the profile for the metadata block groups.
 Valid values are 'raid0', 'raid1', 'raid5', 'raid6', 'raid10', 'single' or
-'dup', (case does not matter).
+'dup' (case does not matter).
 +
-A single device filesystem will default to 'DUP', unless a SSD is detected. Then
-it will default to 'single'. The detection is based on the value of
+A single device filesystem will default to 'DUP', unless an SSD is detected, in which
+case it will default to 'single'. The detection is based on the value of
 `/sys/block/DEV/queue/rotational`, where 'DEV' is the short name of the device.
 +
 Note that the rotational status can be arbitrarily set by the underlying block