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

[Kanchan Joshi <joshi.k@samsung.com>]

On 8/25/2026 12:25 PM, Christoph Hellwig wrote:
> 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.
> 

So based on the above discussion, do you see this as the right interface?

1. FS_IOC_WRITE_STREAM_GET_MAX : query max write streams
2. FS_IOC_WRITE_STREAM_ALLOC: allocate any write stream (if available) 
and return stream fd. No flag whatsoever.
3. FS_IOC_WRITE_STREAM_SET: set write stream into a file using stream-fd