From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Anuj Gupta/Anuj Gupta <anuj20.g@samsung.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
jack@suse.cz, anuj1072538@gmail.com, axboe@kernel.dk,
viro@zeniv.linux.org.uk, brauner@kernel.org, hch@infradead.org,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
joshi.k@samsung.com
Subject: Re: [RFC] fs: add ioctl to query protection info capabilities
Date: Mon, 02 Jun 2025 23:12:38 -0400 [thread overview]
Message-ID: <yq1sekheek9.fsf@ca-mkp.ca.oracle.com> (raw)
In-Reply-To: <fec86763-dd0e-4099-9347-e85aa4a22277@samsung.com> (Anuj Gupta's message of "Thu, 29 May 2025 12:42:45 +0530")
Hi Anuj!
I've been mulling over this for a few days...
> The block layer currently infers this by looking at the csum_type
> (e.g., in blk_integrity_generate). I assumed userspace could do the
> same, so I didn't expose a separate pi_tuple_size field. Do you see
> this differently?
When the block layer data integrity code was originally designed, the
concept of non-PI metadata didn't exist.
Then NVMe came along and we added support for opaque metadata in
addition to the PI.
As a result, the block layer considers the opaque metadata part of the
PI but it technically isn't. It really should be the other way around:
The PI is a subset of the metadata.
It would require quite a bit of rototilling to metadata-ize the block
layer plumbing at this point. But for a new user API, I do think we
should try to align with the architecture outlined in the standards.
--
Martin K. Petersen
next prev parent reply other threads:[~2025-06-03 3:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250527105950epcas5p1b53753ab614bf6bde4ffbf5165c7d263@epcas5p1.samsung.com>
2025-05-27 10:42 ` [RFC] fs: add ioctl to query protection info capabilities Anuj Gupta
2025-05-29 3:02 ` Martin K. Petersen
2025-05-29 7:12 ` Anuj Gupta/Anuj Gupta
2025-05-29 17:59 ` Eric Biggers
2025-05-30 5:24 ` Christian Brauner
2025-06-03 18:43 ` Anuj gupta
2025-06-04 7:53 ` Christian Brauner
2025-06-04 7:57 ` Christoph Hellwig
2025-06-05 8:24 ` Christian Brauner
2025-05-29 21:14 ` [RFC] " Andreas Dilger
2025-06-03 3:12 ` Martin K. Petersen [this message]
2025-06-03 6:30 ` [RFC] fs: " Christoph Hellwig
2025-06-04 1:48 ` Martin K. Petersen
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=yq1sekheek9.fsf@ca-mkp.ca.oracle.com \
--to=martin.petersen@oracle.com \
--cc=anuj1072538@gmail.com \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.