Re: [PATCH v3 2/6] iomap: introduce and propagate write_stream

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

On 6/24/2026 11:40 PM, Darrick J. Wong wrote:
>> diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
>> index b36ee619cdcd..455fd5d97d25 100644
>> --- a/fs/iomap/direct-io.c
>> +++ b/fs/iomap/direct-io.c
>> @@ -348,6 +348,7 @@ static ssize_t iomap_dio_bio_iter_one(struct iomap_iter *iter,
>>   	fscrypt_set_bio_crypt_ctx(bio, iter->inode, pos, GFP_KERNEL);
>>   	bio->bi_iter.bi_sector = iomap_sector(&iter->iomap, pos);
>>   	bio->bi_write_hint = iter->inode->i_write_hint;
>> +	bio->bi_write_stream = iter->iomap.write_stream;
>>   	bio->bi_ioprio = dio->iocb->ki_ioprio;
>>   	bio->bi_private = dio;
>>   	bio->bi_end_io = iomap_dio_bio_end_io;
>> diff --git a/fs/iomap/ioend.c b/fs/iomap/ioend.c
>> index acf3cf98b23a..56ed5ba6a421 100644
>> --- a/fs/iomap/ioend.c
>> +++ b/fs/iomap/ioend.c
>> @@ -164,6 +164,7 @@ static struct iomap_ioend *iomap_alloc_ioend(struct iomap_writepage_ctx *wpc,
>>   			       GFP_NOFS, &iomap_ioend_bioset);
>>   	bio->bi_iter.bi_sector = iomap_sector(&wpc->iomap, pos);
>>   	bio->bi_write_hint = wpc->inode->i_write_hint;
>> +	bio->bi_write_stream = wpc->iomap.write_stream;
>>   	wbc_init_bio(wpc->wbc, bio);
>>   	wpc->nr_folios = 0;
>>   	return iomap_init_ioend(wpc->inode, bio, pos, ioend_flags);
>> @@ -187,6 +188,8 @@ static bool iomap_can_add_to_ioend(struct iomap_writepage_ctx *wpc, loff_t pos,
>>   	if (!(wpc->iomap.flags & IOMAP_F_ANON_WRITE) &&
>>   	    iomap_sector(&wpc->iomap, pos) != bio_end_sector(&ioend->io_bio))
>>   		return false;
>> +	if (wpc->iomap.write_stream != ioend->io_bio.bi_write_stream)
>> +		return false;
>>   	/*
>>   	 * Limit ioend bio chain lengths to minimise IO completion latency. This
>>   	 * also prevents long tight loops ending page writeback on all the
>> diff --git a/include/linux/iomap.h b/include/linux/iomap.h
>> index 2c5685adf3a9..44583429ffa4 100644
>> --- a/include/linux/iomap.h
>> +++ b/include/linux/iomap.h
>> @@ -120,6 +120,8 @@ struct iomap {
>>   	u64			length;	/* length of mapping, bytes */
>>   	u16			type;	/* type of mapping */
>>   	u16			flags;	/* flags for mapping */
>> +	u8			write_stream; /* write stream for I/O */
> I'm mildly confused by the types here -- the ioctl exposes a u32, iomap
> has a u8, and xfs seems to use u16.  I gather you want maximum
> flexibility in the uapi and that's the reason for the u32, but can the
> internal interfaces be made consistent?

Yes, using u16 within iomap will make it better.

> I also wonder what happens if the write stream ever becomes persistent,
> but this patchset doesn't go there, and maybe the programming model is
> simply that you have to set it every time you open the file?

Right, not trying to make things persistent.