From: Damien Le Moal <dlemoal@kernel.org>
To: Andreas Hindborg <nmi@metaspace.dk>,
Bart Van Assche <bvanassche@acm.org>
Cc: "Jens Axboe" <axboe@kernel.dk>, "Christoph Hellwig" <hch@lst.de>,
"Keith Busch" <kbusch@kernel.org>,
"Damien Le Moal" <Damien.LeMoal@wdc.com>,
"Hannes Reinecke" <hare@suse.de>,
"Ming Lei" <ming.lei@redhat.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"Andreas Hindborg" <a.hindborg@samsung.com>,
"Wedson Almeida Filho" <wedsonaf@gmail.com>,
"Greg KH" <gregkh@linuxfoundation.org>,
"Matthew Wilcox" <willy@infradead.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Alice Ryhl" <aliceryhl@google.com>,
"Chaitanya Kulkarni" <chaitanyak@nvidia.com>,
"Luis Chamberlain" <mcgrof@kernel.org>,
"Yexuan Yang" <1182282462@bupt.edu.cn>,
"Sergio González Collado" <sergio.collado@gmail.com>,
"Joel Granados" <j.granados@samsung.com>,
"Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
"Daniel Gomez" <da.gomez@samsung.com>,
"Niklas Cassel" <Niklas.Cassel@wdc.com>,
"Philipp Stanner" <pstanner@redhat.com>,
"Conor Dooley" <conor@kernel.org>,
"Johannes Thumshirn" <Johannes.Thumshirn@wdc.com>,
"Matias Bjørling" <m@bjorling.me>,
"open list" <linux-kernel@vger.kernel.org>,
"rust-for-linux@vger.kernel.org" <rust-for-linux@vger.kernel.org>,
"lsf-pc@lists.linux-foundation.org"
<lsf-pc@lists.linux-foundation.org>,
"gost.dev@samsung.com" <gost.dev@samsung.com>
Subject: Re: [PATCH 1/3] rust: block: introduce `kernel::block::mq` module
Date: Mon, 13 May 2024 22:08:43 +0900 [thread overview]
Message-ID: <f3a5d43c-b94b-49ef-a883-c27e4720c8a5@kernel.org> (raw)
In-Reply-To: <87r0e5j2st.fsf@metaspace.dk>
On 2024/05/13 21:48, Andreas Hindborg wrote:
>
> Hi Bart,
>
> Bart Van Assche <bvanassche@acm.org> writes:
>
>> On 5/12/24 11:39, Andreas Hindborg wrote:
>>> + /// Set the logical block size of the device.
>>> + ///
>>> + /// This is the smallest unit the storage device can address. It is
>>> + /// typically 512 bytes.
>>
>> Hmm ... all block devices that I have encountered recently have a
>> logical block size of 4096 bytes. Isn't this the preferred logical
>> block size for SSDs and for SMR hard disks?
>
> Yes, that is probably true. This text was lifted from the entry on the
> sysfs attribute in `Documentation/ABI/stable/sysfs-block`, but maybe
> that needs to be updated as well.
>
>>
>>> + /// Set the physical block size of the device.
>>> + ///
>>> + /// This is the smallest unit a physical storage device can write
>>> + /// atomically. It is usually the same as the logical block size but may be
>>> + /// bigger. One example is SATA drives with 4KB sectors that expose a
>>> + /// 512-byte logical block size to the operating system.
>>
>> Please be consistent and change "4 KB sectors" into "4 KB physical block
>> size".
>
> OK, I will. I can CC the changes to
> `Documentation/ABI/stable/sysfs-block` then'
>
>>
>> I think that the physical block size can also be smaller than the
>> logical block size. From the SCSI SBC standard:
>>
>> Table 91 — LOGICAL BLOCKS PER PHYSICAL BLOCK EXPONENT field
>> ----- ------------------------------------------------------------
>> Code Description
>> ----- ------------------------------------------------------------
>> 0 One or more physical blocks per logical block (the number of
>> physical blocks per logical block is not reported).
>> n > 0 2**n logical blocks per physical block
>> ----- ------------------------------------------------------------
That text is bad. 0 really means physical == logical. Otherwise, there is no way
to know how to access the drive because the logical size is the unit for
accessing the drive. In practice, the logical block size is always smaller or
equal to the physical block size. The physical block size is always a power of 2
number of logical blocks.
> How does that work? Would the drive do a read/modify/write internally?
Yes.
> Would that not make the physical block size as seen from the OS equal to
> the smaller logical block size?
Not necessarily. There are a lot of 512e drives out there: 4K physical, 512B
logical. So applications/hosts can still do 512B accesses for compatibility but
performance may be bad. For such drive, the user should really do 4K aligned
accesses.
>
>>
>>> +impl<T: Operations, S: GenDiskState> GenDisk<T, S> {
>>> + /// Call to tell the block layer the capacity of the device in sectors (512B).
>>
>> Why to use any other unit than bytes in Rust block::mq APIs? sector_t
>> was introduced before 64-bit CPUs became available to reduce the number
>> of bytes required to represent offsets. I don't think that this is still
>> a concern today. Hence my proposal to be consistent in the Rust block::mq API
>> and to use bytes as the unit in all APIs.
>
> I think that is very good idea. How do others feel about this?
>
> BR Andreas
>
>
--
Damien Le Moal
Western Digital Research
next prev parent reply other threads:[~2024-05-13 13:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-12 18:39 [PATCH 0/3] Rust block device driver API and null block driver Andreas Hindborg
2024-05-12 18:39 ` [PATCH 1/3] rust: block: introduce `kernel::block::mq` module Andreas Hindborg
2024-05-13 12:22 ` Bart Van Assche
2024-05-13 12:48 ` Andreas Hindborg
2024-05-13 13:08 ` Damien Le Moal [this message]
2024-05-12 18:39 ` [PATCH 2/3] rust: block: add rnull, Rust null_blk implementation Andreas Hindborg
2024-05-12 18:39 ` [PATCH 3/3] MAINTAINERS: add entry for Rust block device driver API Andreas Hindborg
2024-05-14 20:00 ` [PATCH 0/3] Rust block device driver API and null block driver Jens Axboe
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=f3a5d43c-b94b-49ef-a883-c27e4720c8a5@kernel.org \
--to=dlemoal@kernel.org \
--cc=1182282462@bupt.edu.cn \
--cc=Damien.LeMoal@wdc.com \
--cc=Johannes.Thumshirn@wdc.com \
--cc=Niklas.Cassel@wdc.com \
--cc=a.hindborg@samsung.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=axboe@kernel.dk \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=bvanassche@acm.org \
--cc=chaitanyak@nvidia.com \
--cc=conor@kernel.org \
--cc=da.gomez@samsung.com \
--cc=gary@garyguo.net \
--cc=gost.dev@samsung.com \
--cc=gregkh@linuxfoundation.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=j.granados@samsung.com \
--cc=kbusch@kernel.org \
--cc=kernel@pankajraghav.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=m@bjorling.me \
--cc=mcgrof@kernel.org \
--cc=ming.lei@redhat.com \
--cc=nmi@metaspace.dk \
--cc=ojeda@kernel.org \
--cc=pstanner@redhat.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=sergio.collado@gmail.com \
--cc=wedsonaf@gmail.com \
--cc=willy@infradead.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;
as well as URLs for NNTP newsgroup(s).