Re: [PATCH v4 1/6] fs: add write-stream management ioctls

[Christoph Hellwig <hch@lst.de>]

On Mon, Aug 24, 2026 at 12:00:46PM +0530, Kanchan Joshi wrote:
> >> - That stream/fd will be unavailable if some other application has
> >> already opened it.
> >> - If applications gets the stream fd, it can use that to set stream id
> >> for multiple files.
> >> - It can close the stream-fd and that does not change anything for the
> >> file resource (i.e, its inode continue to carry the stream-id value that
> >> was set).
> >>
> >> Christoph - does this match?
> > 
> > Almost.  I didn't really think of your last point there.  If the
> > inodes keeps using it when it is dropped that breaks the model a
> > bit, but revoking it might make things a bit ugly and slow.  Urgg.
> 
> I think it is consistent to the model that says stream fd is a distinct 
> resource and it is a necessary lease/license to set the particular 
> stream(-id) across files.
> If the stream-fd is held, that stream-id remains exclusive to the 
> application.
> Closing means, applications is fine to release the license and 
> underlying stream-id becomes available to other users.

But that also means it can be reallocated to other users, which
now mix data.  I guess the answer might be "don't do this", but
I'd love to have interfaces that aren't easy to abuse.  OTOH
implementing this might be quite an overhead.

> >> 4. FS_IOC_QUERY_FILE_WRITE_STREAM_ID		_IOR('f', 138, __u32)
> >>
> >> Queries the write-stream value (__u32) currently assigned to the file
> >> (its inode).
> > 
> > I'm not sure exposing the actual ID to the user space application is a
> > that good idea, 
> 
> But don't we need a way to know if stream id/value is set on a file or 
> not? This ioctl is more about observability; GET equivalent of SET.
> Also write stream value is not going to be there if/when in-core inode 
> gets evicted.

Yes, but the application needs to basically set it after open
anyway.  Keeping any kind of state over a file descriptor that
has been closed doesn't make much sense.

> > same for passing in the wanted ID when allocating.
> 
> Can drop OPEN_EXACT flag if you prefer that.
> But this was for the case if application restarted and wanted its new 
> data to go into the bucket where it was previously writing.

But that assumes that the bucket hasn't otherwise been reused, which
might not be the case.

> > That leaks a lot of internal details.
> 
> I viewed stream-id similar to how we view file-name. Application can 
> list file names, but need the fd to do operations on that file.
> So, I could not understand internal details part. Could you explain? We 
> have FIEMAP and unprivileged XFS_IOC_FSGEOMETRY already expose the 
> placement of the file.

There are a lot of operations on filenames.. XFS_IOC_FSGEOMETRY and
are in a different register than normal file operations.  If we
want to expose the mapped stream IDs I'd also rather have them in
a different register than the usual APIs.