| Message ID | 20191017045006.130378-1-merlin.buege@tuhh.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs-progs: small fixes/cleanup in Documentation | expand |
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 >
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.
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.
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.
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.
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