From: Karel Zak <kzak@redhat.com>
To: "Pádraig Brady" <P@draigBrady.com>
Cc: "Richard W.M. Jones" <rjones@redhat.com>, util-linux@vger.kernel.org
Subject: Re: [PATCH] blockdev: Remove the --setbsz (set blocksize) option which has never worked.
Date: Wed, 9 Oct 2013 11:31:02 +0200 [thread overview]
Message-ID: <20131009093102.GI13559@x2.net.home> (raw)
In-Reply-To: <52542B27.4050901@draigBrady.com>
On Tue, Oct 08, 2013 at 04:56:23PM +0100, Pádraig Brady wrote:
> For my own reference, the way I see it,
> when accessing block devices Linux uses these block sizes:
>
> physical defined by the hardware device
> logical the smallest addressable unit used for the device
> file system ditto for the file system
>
> --[gs]etbsz refers the _logical_ block size for the device.
Well, let's be more pedantic ;-)
The disks and raids provides I/O limits:
physical block size (BLKPBSZGET)
logical block size (BLKSSZGET)
but kernel also uses
soft block size BLKBSZGET
this size is never smaller than logical size and (I guess) usually
same as PAGE_SIZE. So it's really not *device* logical block size,
it's more about the way how kernel uses the device.
> So why might one want to --setbsz?
> I agree that would be fairly specialized.
Yes, it's practically useless in tool like blockdev(8).
> I searched for uses of --setbz and noticed a couple:
> Perf testing:
> https://lkml.org/lkml/2003/12/30/81
> Functionality testing:
> http://www.linux-archive.org/device-mapper-development/699549-blockdev-fix-crash-when-block-size-changed-i-o-issued-simultaneously.html
Good point (it seems I was too rash to apply Rich's patch;-)
Maybe we can keep --setbsz in the code for testing purpose and for
backward compatibility, then all we need is describe the ioctl in the
blockdev(8) man page.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
next prev parent reply other threads:[~2013-10-09 9:31 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 8:54 [PATCH] blockdev: Remove the --setbsz (set blocksize) option which has never worked Richard W.M. Jones
2013-10-08 13:56 ` Karel Zak
2013-10-08 14:05 ` Pádraig Brady
2013-10-08 14:09 ` Richard W.M. Jones
2013-10-08 15:56 ` Pádraig Brady
2013-10-09 9:31 ` Karel Zak [this message]
2013-10-11 9:18 ` Karel Zak
2013-10-09 10:52 ` Richard W.M. Jones
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=20131009093102.GI13559@x2.net.home \
--to=kzak@redhat.com \
--cc=P@draigBrady.com \
--cc=rjones@redhat.com \
--cc=util-linux@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