linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] btrfs-progs: small fixes/cleanup in Documentation
@ 2019-10-17  4:50 Merlin Büge
  2019-10-17  6:29 ` Nikolay Borisov
  2019-10-18 16:14 ` [PATCH v2] " Merlin Büge
  0 siblings, 2 replies; 10+ messages in thread
From: Merlin Büge @ 2019-10-17  4:50 UTC (permalink / raw)
  To: linux-btrfs; +Cc: Merlin Büge

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(-)

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


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: small fixes/cleanup in Documentation
  2019-10-17  4:50 [PATCH] btrfs-progs: small fixes/cleanup in Documentation Merlin Büge
@ 2019-10-17  6:29 ` Nikolay Borisov
  2019-10-17 11:18   ` David Sterba
  2019-10-18 16:14 ` [PATCH v2] " Merlin Büge
  1 sibling, 1 reply; 10+ messages in thread
From: Nikolay Borisov @ 2019-10-17  6:29 UTC (permalink / raw)
  To: Merlin Büge, linux-btrfs



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
> 

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: small fixes/cleanup in Documentation
  2019-10-17  6:29 ` Nikolay Borisov
@ 2019-10-17 11:18   ` David Sterba
  2019-10-17 14:47     ` Merlin Büge
  0 siblings, 1 reply; 10+ messages in thread
From: David Sterba @ 2019-10-17 11:18 UTC (permalink / raw)
  To: Nikolay Borisov; +Cc: Merlin Büge, linux-btrfs

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: small fixes/cleanup in Documentation
  2019-10-17 11:18   ` David Sterba
@ 2019-10-17 14:47     ` Merlin Büge
  2019-10-18 12:07       ` David Sterba
  0 siblings, 1 reply; 10+ messages in thread
From: Merlin Büge @ 2019-10-17 14:47 UTC (permalink / raw)
  To: David Sterba; +Cc: Nikolay Borisov, linux-btrfs



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.
-- 
Merlin Büge

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: small fixes/cleanup in Documentation
  2019-10-17 14:47     ` Merlin Büge
@ 2019-10-18 12:07       ` David Sterba
  2019-10-18 14:56         ` Merlin Büge
  0 siblings, 1 reply; 10+ messages in thread
From: David Sterba @ 2019-10-18 12:07 UTC (permalink / raw)
  To: Merlin Büge; +Cc: David Sterba, Nikolay Borisov, linux-btrfs

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] btrfs-progs: small fixes/cleanup in Documentation
  2019-10-18 12:07       ` David Sterba
@ 2019-10-18 14:56         ` Merlin Büge
  0 siblings, 0 replies; 10+ messages in thread
From: Merlin Büge @ 2019-10-18 14:56 UTC (permalink / raw)
  To: David Sterba; +Cc: Nikolay Borisov, linux-btrfs



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.

-- 
Merlin Büge

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [PATCH v2] btrfs-progs: small fixes/cleanup in Documentation
  2019-10-17  4:50 [PATCH] btrfs-progs: small fixes/cleanup in Documentation Merlin Büge
  2019-10-17  6:29 ` Nikolay Borisov
@ 2019-10-18 16:14 ` Merlin Büge
  2019-10-18 16:23   ` Merlin Büge
  1 sibling, 1 reply; 10+ messages in thread
From: Merlin Büge @ 2019-10-18 16:14 UTC (permalink / raw)
  To: merlin.buege; +Cc: linux-btrfs, Nikolay Borisov, David Sterba

The removed paragraph in btrfs-man5.asciidoc says the same as the
previous one.

Signed-off-by: Merlin Büge <merlin.buege@tuhh.de>
---
v2:
 - added SOB line
 - one more typo fix in Documentation/btrfs-man5.asciidoc

 Documentation/btrfs-man5.asciidoc |  8 +-------
 Documentation/mkfs.btrfs.asciidoc | 10 +++++-----
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/Documentation/btrfs-man5.asciidoc b/Documentation/btrfs-man5.asciidoc
index 6a1a04b7..ee6010fe 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*::
@@ -659,7 +653,7 @@ swapfile extents or may fail:
 * resize shrink - works as long as the extents are outside of the shrunk range
 * device add - a new device does not interfere with existing swapfile and this operation will work, though no new swapfile can be activated afterwards
 * device delete - if the device has been added as above, it can be also deleted
-* device replace - dtto
+* device replace - ditto
  
 When there are no active swapfiles and a whole-filesystem exclusive operation
 is running (ie. balance, device delete, shrink), the swapfiles cannot be
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
-- 
2.23.0


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH v2] btrfs-progs: small fixes/cleanup in Documentation
  2019-10-18 16:14 ` [PATCH v2] " Merlin Büge
@ 2019-10-18 16:23   ` Merlin Büge
  2019-10-21 12:30     ` David Sterba
  0 siblings, 1 reply; 10+ messages in thread
From: Merlin Büge @ 2019-10-18 16:23 UTC (permalink / raw)
  To: merlin.buege; +Cc: linux-btrfs, Nikolay Borisov, David Sterba



On Fri, 18 Oct 2019 18:14:33 +0200
Merlin Büge <merlin.buege@tuhh.de> wrote:
...
> diff --git a/Documentation/btrfs-man5.asciidoc b/Documentation/btrfs-man5.asciidoc
> index 6a1a04b7..ee6010fe 100644
> --- a/Documentation/btrfs-man5.asciidoc
> +++ b/Documentation/btrfs-man5.asciidoc
...
> @@ -659,7 +653,7 @@ swapfile extents or may fail:
...
> -* device replace - dtto
> +* device replace - ditto

I think I may have got that last one wrong, sorry.
I've never seen it spelled 'dtto', but I now see further references e.g.
here:
https://github.com/kdave/btrfs-progs/blob/master/Makefile

So, feel free to pick v1/v2 which you find the most appropriate!

Thanks.
-- 
Merlin Büge

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2] btrfs-progs: small fixes/cleanup in Documentation
  2019-10-18 16:23   ` Merlin Büge
@ 2019-10-21 12:30     ` David Sterba
  2019-10-21 12:59       ` Merlin Büge
  0 siblings, 1 reply; 10+ messages in thread
From: David Sterba @ 2019-10-21 12:30 UTC (permalink / raw)
  To: Merlin Büge; +Cc: linux-btrfs, Nikolay Borisov, David Sterba

On Fri, Oct 18, 2019 at 06:23:31PM +0200, Merlin Büge wrote:
> 
> 
> On Fri, 18 Oct 2019 18:14:33 +0200
> Merlin Büge <merlin.buege@tuhh.de> wrote:
> ...
> > diff --git a/Documentation/btrfs-man5.asciidoc b/Documentation/btrfs-man5.asciidoc
> > index 6a1a04b7..ee6010fe 100644
> > --- a/Documentation/btrfs-man5.asciidoc
> > +++ b/Documentation/btrfs-man5.asciidoc
> ...
> > @@ -659,7 +653,7 @@ swapfile extents or may fail:
> ...
> > -* device replace - dtto
> > +* device replace - ditto
> 
> I think I may have got that last one wrong, sorry.
> I've never seen it spelled 'dtto', but I now see further references e.g.
> here:
> https://github.com/kdave/btrfs-progs/blob/master/Makefile
> 
> So, feel free to pick v1/v2 which you find the most appropriate!

I've merged the patch as-is, thank. The 'ditto' spelling is probably
more widely used in english texts. 'dtto' is in sources and thus not
visible to wide audience so we can live with that.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH v2] btrfs-progs: small fixes/cleanup in Documentation
  2019-10-21 12:30     ` David Sterba
@ 2019-10-21 12:59       ` Merlin Büge
  0 siblings, 0 replies; 10+ messages in thread
From: Merlin Büge @ 2019-10-21 12:59 UTC (permalink / raw)
  To: David Sterba; +Cc: linux-btrfs, Nikolay Borisov



On Mon, 21 Oct 2019 14:30:50 +0200
David Sterba <dsterba@suse.cz> wrote:
...
> I've merged the patch as-is, thank. The 'ditto' spelling is probably
> more widely used in english texts. 'dtto' is in sources and thus not
> visible to wide audience so we can live with that.

Thank you!

-- 
Merlin Büge

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2019-10-21 12:59 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-17  4:50 [PATCH] btrfs-progs: small fixes/cleanup in Documentation Merlin Büge
2019-10-17  6:29 ` Nikolay Borisov
2019-10-17 11:18   ` David Sterba
2019-10-17 14:47     ` Merlin Büge
2019-10-18 12:07       ` David Sterba
2019-10-18 14:56         ` Merlin Büge
2019-10-18 16:14 ` [PATCH v2] " Merlin Büge
2019-10-18 16:23   ` Merlin Büge
2019-10-21 12:30     ` David Sterba
2019-10-21 12:59       ` Merlin Büge

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).