public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
* [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