public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: dsterba@suse.cz
Cc: Qu Wenruo <wqu@suse.com>, David Disseldorp <ddiss@suse.de>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: drop unused memparse() parameter
Date: Thu, 14 Dec 2023 10:16:47 +1030	[thread overview]
Message-ID: <32a3cfc2-a38e-4ddc-8dd6-c9c1928005e5@gmx.com> (raw)
In-Reply-To: <20231213231552.GK3001@twin.jikos.cz>



On 2023/12/14 09:45, David Sterba wrote:
> On Fri, Dec 08, 2023 at 06:26:50AM +1030, Qu Wenruo wrote:
>>> The value that can be read from the sysfs file is in bytes and it's so
>>> that applications do not need to interpret it, like multiplying with
>>> 1024. We'll probably never return the pretty values with suffixes in
>>> sysfs files.
>>>
>>> However, on the input side the suffixes are a convenience, setting to
>>> limit the throughput as '32m' is better than typing '32000000' and
>>> counting zeros or $((32*1024*1024)) or 33554432.
>>>
>>> This is why memparse is there and kstrtoull does not do that.
>>
>> That suffix is causing confusion already, just check my "25e" case.
>> (It does not only lead to huge number, but also lead to incorrect value
>> even if we treat "e" as a suffix)
>>
>> Furthermore, the convenience argument is not that strong, you won't
>> expect end users to do the change for a fs every time.
>> Thus it's mostly managed by a small script or some other tool.
>>
>> In that case I don't think doing extra bash calculation is a big deal
>> anyway.
>
> This is a nice study of convenience vs extra work "that's no big deal".
> The sysfs files can be used by scripts, often times it's the only access
> to some settings (like /usr/bin/rescan-scsi-bus.sh/usr/bin/rescan-scsi-bus.sh).
> The value format, naming of the sysfs files is inconsistent and
> navigating to a particular directory and setting some magic value is I
> think common. Another example are trace points, or dynamic printk.
>
> There are tools abstracting that but sometimes it's a person that needs
> to type it and the shortcuts like the suffix are convenient because
> there's no extra need to type exact syntax and numbers for a $((...))
> expression. Ask 3 people if they'd prefer to type "4m" or
> "$((4*1024*1024))".
>
> If you ask me I'm all for allowing "4m" and I did that several times
> when testing things like the discard tunables, chunk size or the scrub
> limits. I consider the sysfs files an interface for human interaction so
> even if it's used like that in 10% of time it's still saving typing or
> allowing one to focus on the real prolem instead of shell sytax.
>

OK, then let me jump into the rabbit hole of stroxll family for my
holiday projects, to make the memparse() itself more reliable and get
rid of the caveats.

Hopefully allowing callers to select which suffixes they want to use.

(Well, at least I hope "25e" can give us a correct value after the fix)

Thanks,
Qu

      reply	other threads:[~2023-12-13 23:46 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05 11:13 [PATCH] btrfs: drop unused memparse() parameter David Disseldorp
2023-12-05 12:48 ` Johannes Thumshirn
2023-12-05 14:22 ` David Sterba
2023-12-06  0:21   ` David Disseldorp
2023-12-06 18:53     ` David Sterba
2023-12-06 23:52       ` David Disseldorp
2023-12-07 13:55         ` David Sterba
2023-12-08  0:41           ` [PATCH] btrfs: validate scrub_speed_max sysfs string David Disseldorp
2023-12-11  3:18             ` Qu Wenruo
2023-12-11  3:56               ` David Disseldorp
2023-12-13 22:50               ` David Sterba
2023-12-13 22:52             ` David Sterba
2023-12-07  2:31 ` [PATCH] btrfs: drop unused memparse() parameter Qu Wenruo
2023-12-07 12:15   ` David Sterba
2023-12-07 19:56     ` Qu Wenruo
2023-12-13 23:15       ` David Sterba
2023-12-13 23:46         ` Qu Wenruo [this message]

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=32a3cfc2-a38e-4ddc-8dd6-c9c1928005e5@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=ddiss@suse.de \
    --cc=dsterba@suse.cz \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /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