* [LSF/MM/BPF TOPIC] FDP file I/O via write-streams
[not found] <CGME20260220110725epcas5p41a6ae8751fee9782f338cbd66dd2700d@epcas5p4.samsung.com>
@ 2026-02-20 11:07 ` Kanchan Joshi
2026-02-20 15:11 ` Christoph Hellwig
0 siblings, 1 reply; 4+ messages in thread
From: Kanchan Joshi @ 2026-02-20 11:07 UTC (permalink / raw)
To: lsf-pc@lists.linux-foundation.org, linux-fsdevel
Cc: Christian Brauner, Christoph Hellwig, Darrick J. Wong,
Keith Busch, jack, amir73il
I have been unsure whether to propose this, hence the last-minute
submission.
We discussed the topic over patchsets and at the last LSFMM [1].
The block IO support along with the new construct 'write-stream'
(distinct from the existing write-hint) landed after that.
As a quick refresher: while Linux supports write-stream based
placement for the block IO path (since 6.16), the capability remains
inaccessible to standard file-based applications.
For file IO support, I posted an RFC [2] with a new fcntl-based
'write-stream' user-interface last year.
The feedback was to streamline the kernel-internal plumbing, and the
new patches [3] are aligned with that direction.
To summarize, the current patches contain two parts:
- A new stream-management interface at the VFS layer
- XFS support for this interface
The motivation, design, and implementation choices are detailed in the
cover letter.
I am yet to get feedback on the XFS portion, but the VFS part seems fine
following a shift from an fcntl-based interface to an ioctl-based one.
Since we have iterated through multiple schemes to arrive at the current
one, I believe the most thorny issues have been resolved.
And simpler things can just get ironed out as I refine patches with the
incoming feedback.
But a discussion will be useful if anything (heaven forbid) emerges that
requires hashing things out in-person.
[1] https://lwn.net/Articles/1018642/
[2]
https://lore.kernel.org/linux-fsdevel/20250729145135.12463-1-joshi.k@samsung.com/
[3]
https://lore.kernel.org/linux-block/20260216052540.217920-1-joshi.k@samsung.com/
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LSF/MM/BPF TOPIC] FDP file I/O via write-streams
2026-02-20 11:07 ` [LSF/MM/BPF TOPIC] FDP file I/O via write-streams Kanchan Joshi
@ 2026-02-20 15:11 ` Christoph Hellwig
2026-02-20 19:51 ` Kanchan Joshi
0 siblings, 1 reply; 4+ messages in thread
From: Christoph Hellwig @ 2026-02-20 15:11 UTC (permalink / raw)
To: Kanchan Joshi
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel,
Christian Brauner, Christoph Hellwig, Darrick J. Wong,
Keith Busch, jack, amir73il
I think you'll get much better traction if you don't tie a high-level
feature to the buzzword of yesteryear as one possible implementation.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LSF/MM/BPF TOPIC] FDP file I/O via write-streams
2026-02-20 15:11 ` Christoph Hellwig
@ 2026-02-20 19:51 ` Kanchan Joshi
2026-02-23 13:53 ` Christoph Hellwig
0 siblings, 1 reply; 4+ messages in thread
From: Kanchan Joshi @ 2026-02-20 19:51 UTC (permalink / raw)
To: Christoph Hellwig
Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel,
Christian Brauner, Darrick J. Wong, Keith Busch, jack, amir73il
On 2/20/2026 8:41 PM, Christoph Hellwig wrote:
> I think you'll get much better traction if you don't tie a high-level
> feature to the buzzword of yesteryear as one possible implementation.
>
Let me confirm my understanding. Perhaps this is about using the term
stream in the UAPI naming (i.e., FS_IOC_WRITE_STREAM ioctl) and the
concern is that it reminds of the older NVMe multi-stream (streams
directive) feature?
My thought process was: block-layer already abstracts the
hardware-specific implementation (NVMe FDP's placement id/RUHs) into
generic write-stream construct (and this name is also used in io_uring
SQE for per I/O), so it seemed fine to extend the existing block-layer
terminology up to the VFS user-interface.
If I decouple the user-facing interface (and also iomap and xfs inode
too) from block-layer's naming, would one of the following address the
concern and be more palatable for VFS-level abstraction?
- FS_IOC_PLACEMENT_GROUP (or _CLASS)
- FS_IOC_WRITE_GROUP
But if you meant something else (that should be changed in patches),
please elaborate.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [LSF/MM/BPF TOPIC] FDP file I/O via write-streams
2026-02-20 19:51 ` Kanchan Joshi
@ 2026-02-23 13:53 ` Christoph Hellwig
0 siblings, 0 replies; 4+ messages in thread
From: Christoph Hellwig @ 2026-02-23 13:53 UTC (permalink / raw)
To: Kanchan Joshi
Cc: Christoph Hellwig, lsf-pc@lists.linux-foundation.org,
linux-fsdevel, Christian Brauner, Darrick J. Wong, Keith Busch,
jack, amir73il
On Sat, Feb 21, 2026 at 01:21:38AM +0530, Kanchan Joshi wrote:
> On 2/20/2026 8:41 PM, Christoph Hellwig wrote:
> > I think you'll get much better traction if you don't tie a high-level
> > feature to the buzzword of yesteryear as one possible implementation.
> >
> Let me confirm my understanding. Perhaps this is about using the term
> stream in the UAPI naming (i.e., FS_IOC_WRITE_STREAM ioctl) and the
> concern is that it reminds of the older NVMe multi-stream (streams
> directive) feature?
>
It's about your use of FDP in the subject.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-02-23 13:53 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <CGME20260220110725epcas5p41a6ae8751fee9782f338cbd66dd2700d@epcas5p4.samsung.com>
2026-02-20 11:07 ` [LSF/MM/BPF TOPIC] FDP file I/O via write-streams Kanchan Joshi
2026-02-20 15:11 ` Christoph Hellwig
2026-02-20 19:51 ` Kanchan Joshi
2026-02-23 13:53 ` Christoph Hellwig
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox