linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: ericonr@disroot.org
To: linux-f2fs-devel@lists.sourceforge.net
Subject: [f2fs-dev] f2fs-tools: Question about mkfs and fsck behavior for documentation purposes
Date: Thu, 09 Apr 2020 03:44:34 +0000	[thread overview]
Message-ID: <ecfeeb92efb299cce883d25a4669fbd5@disroot.org> (raw)

Hi there!

I'm working on the man pages and usage messages of the various f2fs
tools, to make them more descriptive and correspond better to what the
code is doing.  So I'm hunting around the f2fs-tools tree to try to
understand things, but I'd like to confirm some ideas I have.

- Inside mkfs, the overprovision percentage is either provided by the
user (-o option) or determined by the program.  The current usage text
says the default is 5. Should I remove this default to make it clear
that if no percentage is provided, it is determined at runtime?

- For the -c option in mkfs, it says there's a maximum of 7 additional
devices, except for "meta devices". What is a meta device? Given that
the code for parsing arguments passed to -c doesn't seem to
distinguish between meta or normal devices, can I remove this part of
the text?

- The verity feature has a "Reserved" comment next to it, but it is used
by the Android default options. Should I therefore not document it in
the options for -O?

- I documented the -g option as "Add Android default options". Is there
a better description for it?

- mkfs uses -e and -E to specify the file extensions for cold and hot
files. Is there anywhere I can find a small explanation of what these
features mean to include in the man pages? I kind of understood that
they differ in what the filesystem expects will be their lifetime and
access patterns, but I don't know how to communicate this adequately.

- fsck, during the feature parsing phase, doesn't seem to pass any
specific argument to  parse_feature(). Does that mean all extra
features can be enabled by fsck, even if they weren't enabled when the
filesystem was created?

More generally, I've fixed a few typos along the way as well. Is it ok
if I put everything together into a single commit when I make a patch?

Another question regarding preferences: both here and in the
documentation of other tools like mkfs.ext4, "filesystem" is written all
together and as "file system". Is there any preferred spelling for new
content?

Thanks,

Érico Nogueira


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

             reply	other threads:[~2020-04-09  3:44 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-09  3:44 ericonr [this message]
2020-04-13 17:15 ` [f2fs-dev] f2fs-tools: Question about mkfs and fsck behavior for documentation purposes Jaegeuk Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ecfeeb92efb299cce883d25a4669fbd5@disroot.org \
    --to=ericonr@disroot.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).