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

On 8/19/2026 12:38 PM, Christoph Hellwig wrote:
> On Thu, Jul 30, 2026 at 08:22:51PM +0530, Kanchan Joshi wrote:
>> Christoph's idea was to use FD for a write-stream so that it remains
>> exclusive to the application and unrelated applications don't collide.
>>
>> So, in this version, write-stream ids are implemented as independent
>> resource:
>> - To set a file's write-stream ID to X, the app must first obtain the fd
>> for stream X.
>> - 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.
Application may use stream-fd license and set corresponding write-stream 
id into N files. We don't need to track those N files and negate the 
effect (clear stream-id in those N inodes) when the license was released.

>> Here are the revised names (suggestions?):
>>
>> 1. FS_IOC_QUERY_MAX_WRITE_STREAM_IDS		_IOR('f', 135, __u32)
>>
>> Returns (in __u32) number of supported stream-ids.
>>
>> 2. FS_IOC_OPEN_WRITE_STREAM_ID			_IOWR('f', 136, struct
>> fs_write_stream_open)
>>
>> Open the specific write-stream id (or any available one via a flag) and
>> return its FD. This gives right to use that stream-id.
> 
> maybe s/OPEN/ALLOC(ATA)/ ?

Yes.
If we are doing away with stream-id, ALLOC is better.
If we retain (as this version does), OPEN may still be better.

>> And the following manage setting/clearing/querying write-stream on the file:
>>
>> 3. FS_IOC_SET_FILE_WRITE_STREAM_BY_FD		_IOW('f', 137, __s32)
>>
>> Sets a file's write-stream value (in inode) to whatever the stream fd
>> (passed as __s32) carries. So one never sets scalar values into a file
>> directly.
> 
> I'd drop the _BY_FD.

Sure, I will drop.

That said, we may need a way to clear the stream-id of a file.
We don't need stream-fd for that. An explicit flag here can convey that 
intent.

>>
>> 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.

> 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.
> 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.