From: Christoph Hellwig <hch@infradead.org>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Anuj Gupta/Anuj Gupta <anuj20.g@samsung.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, 2 Jun 2025 23:30:36 -0700 [thread overview]
Message-ID: <aD6WjAVeSL0tNv7D@infradead.org> (raw)
In-Reply-To: <yq1sekheek9.fsf@ca-mkp.ca.oracle.com>
On Mon, Jun 02, 2025 at 11:12:38PM -0400, Martin K. Petersen wrote:
> 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.
As in exporting the total metadata size and PI tuple size?
next prev parent reply other threads:[~2025-06-03 6:30 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 ` [RFC] fs: " Martin K. Petersen
2025-06-03 6:30 ` Christoph Hellwig [this message]
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=aD6WjAVeSL0tNv7D@infradead.org \
--to=hch@infradead.org \
--cc=anuj1072538@gmail.com \
--cc=anuj20.g@samsung.com \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=joshi.k@samsung.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--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.