From: "Theodore Ts'o" <tytso@mit.edu>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH 1/2] common: check if the scratch device can support 1024 block sizes
Date: Mon, 23 Oct 2023 15:48:22 -0400 [thread overview]
Message-ID: <20231023194822.GA2840460@mit.edu> (raw)
In-Reply-To: <20231023154513.GF11391@frogsfrogsfrogs>
On Mon, Oct 23, 2023 at 08:45:13AM -0700, Darrick J. Wong wrote:
> > + if [ $blocksize -lt $(blockdev --getss $SCRATCH_DEV) ]; then
> > + _require_scratch_support_blocksize "$blocksize"
> > + fi
>
> This duplicates the logic in _require_scratch_support_blocksize, so I
> think you can drop it.
Yes, oops. I'll drop the if statement.
> > +_require_scratch_support_blocksize()
> > +{
> > + local blocksize=$1
> > +
> > + if [ $blocksize -lt $(blockdev --getss $SCRATCH_DEV) ]; then
> > + _notrun "$SCRATCH_DEV does not support a block size of $blocksize."
>
> "block" is a bit vague in this context -- you mean the LBA size, not the
> internal physical block size, right?
>
> May I suggest "...does not support an LBA size of $blocksize." ?
How about "does not support a file system block size of $blocksize"?
LBA size refers to the granularity of "logical block address" for a
particular block device, which would be confusing and not quite right
here.
- Ted
next prev parent reply other threads:[~2023-10-23 19:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-22 21:55 [PATCH 0/2] Fix test failures caused by storage devcies with 4k sectors Theodore Ts'o
2023-10-22 21:55 ` [PATCH 1/2] common: check if the scratch device can support 1024 block sizes Theodore Ts'o
2023-10-23 15:45 ` Darrick J. Wong
2023-10-23 19:48 ` Theodore Ts'o [this message]
2023-10-22 21:55 ` [PATCH 2/2] generic/563: create the loop dev with the same block size as the scratch dev Theodore Ts'o
2023-10-23 15:54 ` Darrick J. Wong
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=20231023194822.GA2840460@mit.edu \
--to=tytso@mit.edu \
--cc=djwong@kernel.org \
--cc=fstests@vger.kernel.org \
/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