From: "Darrick J. Wong" <djwong@kernel.org>
To: Kanchan Joshi <joshi.k@samsung.com>
Cc: brauner@kernel.org, hch@lst.de, jack@suse.cz, cem@kernel.org,
kbusch@kernel.org, axboe@kernel.dk, linux-xfs@vger.kernel.org,
linux-fsdevel@vger.kernel.org, gost.dev@samsung.com
Subject: Re: [PATCH v2 3/5] xfs: implement write-stream management support
Date: Mon, 9 Mar 2026 09:38:39 -0700 [thread overview]
Message-ID: <20260309163839.GG6033@frogsfrogsfrogs> (raw)
In-Reply-To: <20260309052944.156054-4-joshi.k@samsung.com>
On Mon, Mar 09, 2026 at 10:59:42AM +0530, Kanchan Joshi wrote:
> Implement support for FS_IOC_WRITE_STREAM ioctl.
>
> For FS_WRITE_STREAM_OP_GET_MAX, available write streams are reported
> based on the capability of the underlying block device.
> For FS_WRITE_STREAM_OP_{SET/GET}, add a new i_write_stream field in xfs
> inode. This value is propagated to the iomap during block mapping.
>
> Signed-off-by: Kanchan Joshi <joshi.k@samsung.com>
> ---
> fs/xfs/xfs_icache.c | 1 +
> fs/xfs/xfs_inode.c | 46 +++++++++++++++++++++++++++++++++++++++++++++
> fs/xfs/xfs_inode.h | 6 ++++++
> fs/xfs/xfs_ioctl.c | 34 +++++++++++++++++++++++++++++++++
> fs/xfs/xfs_iomap.c | 1 +
> 5 files changed, 88 insertions(+)
>
> diff --git a/fs/xfs/xfs_icache.c b/fs/xfs/xfs_icache.c
> index a7a09e7eec81..2ad8d02152f4 100644
> --- a/fs/xfs/xfs_icache.c
> +++ b/fs/xfs/xfs_icache.c
> @@ -130,6 +130,7 @@ xfs_inode_alloc(
> spin_lock_init(&ip->i_ioend_lock);
> ip->i_next_unlinked = NULLAGINO;
> ip->i_prev_unlinked = 0;
> + ip->i_write_stream = 0;
>
> return ip;
> }
> diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> index 50c0404f9064..9b88b2d1cf9a 100644
> --- a/fs/xfs/xfs_inode.c
> +++ b/fs/xfs/xfs_inode.c
> @@ -47,6 +47,52 @@
>
> struct kmem_cache *xfs_inode_cache;
>
> +int
> +xfs_inode_max_write_streams(
> + struct xfs_inode *ip)
> +{
> + struct xfs_mount *mp = ip->i_mount;
> + struct block_device *bdev;
> +
> + if (XFS_IS_REALTIME_INODE(ip))
> + bdev = mp->m_rtdev_targp ? mp->m_rtdev_targp->bt_bdev : NULL;
Uhh if this is a realtime inode then there had better be an
m_rtdev_targp to dereference.
Also... this is xfs_inode_buftarg().
> + else
> + bdev = mp->m_ddev_targp->bt_bdev;
> +
> + if (!bdev)
> + return 0;
> +
> + return bdev_max_write_streams(bdev);
> +}
> +
> +uint8_t
> +xfs_inode_get_write_stream(
> + struct xfs_inode *ip)
> +{
> + uint8_t stream_id;
> +
> + xfs_ilock(ip, XFS_ILOCK_SHARED);
> + stream_id = ip->i_write_stream;
> + xfs_iunlock(ip, XFS_ILOCK_SHARED);
> +
> + return stream_id;
> +}
> +
> +int
> +xfs_inode_set_write_stream(
> + struct xfs_inode *ip,
> + uint8_t stream_id)
> +{
> + if (stream_id > xfs_inode_max_write_streams(ip))
Inodes can change devices, so this needs to go under the ILOCK.
> + return -EINVAL;
> +
> + xfs_ilock(ip, XFS_ILOCK_EXCL);
> + ip->i_write_stream = stream_id;
> + xfs_iunlock(ip, XFS_ILOCK_EXCL);
> +
> + return 0;
> +}
> +
> /*
> * These two are wrapper routines around the xfs_ilock() routine used to
> * centralize some grungy code. They are used in places that wish to lock the
> diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h
> index bd6d33557194..9f6cab729924 100644
> --- a/fs/xfs/xfs_inode.h
> +++ b/fs/xfs/xfs_inode.h
> @@ -38,6 +38,9 @@ typedef struct xfs_inode {
> struct xfs_ifork i_df; /* data fork */
> struct xfs_ifork i_af; /* attribute fork */
>
> + /* Write stream information */
> + uint8_t i_write_stream;
I'm confused, bdev_max_write_streams returns an unsigned short, but this
is a uint8_t field. How are we supposed to deal with truncation issues?
--D
> +
> /* Transaction and locking information. */
> struct xfs_inode_log_item *i_itemp; /* logging information */
> struct rw_semaphore i_lock; /* inode lock */
> @@ -676,4 +679,7 @@ int xfs_icreate_dqalloc(const struct xfs_icreate_args *args,
> struct xfs_dquot **udqpp, struct xfs_dquot **gdqpp,
> struct xfs_dquot **pdqpp);
>
> +int xfs_inode_max_write_streams(struct xfs_inode *ip);
> +uint8_t xfs_inode_get_write_stream(struct xfs_inode *ip);
> +int xfs_inode_set_write_stream(struct xfs_inode *ip, uint8_t stream_id);
> #endif /* __XFS_INODE_H__ */
> diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
> index facffdc8dca8..091d6a8b5f57 100644
> --- a/fs/xfs/xfs_ioctl.c
> +++ b/fs/xfs/xfs_ioctl.c
> @@ -1160,6 +1160,38 @@ xfs_ioctl_fs_counts(
> return 0;
> }
>
> +static int
> +xfs_ioc_write_stream(
> + struct file *filp,
> + void __user *arg)
> +{
> + struct inode *inode = file_inode(filp);
> + struct xfs_inode *ip = XFS_I(inode);
> + struct fs_write_stream ws = { };
> +
> + if (copy_from_user(&ws, arg, sizeof(ws)))
> + return -EFAULT;
> +
> + switch (ws.op_flags) {
> + case FS_WRITE_STREAM_OP_GET_MAX:
> + ws.max_streams = xfs_inode_max_write_streams(ip);
> + goto copy_out;
> + case FS_WRITE_STREAM_OP_GET:
> + ws.stream_id = xfs_inode_get_write_stream(ip);
> + goto copy_out;
> + case FS_WRITE_STREAM_OP_SET:
> + return xfs_inode_set_write_stream(ip, ws.stream_id);
> + default:
> + return -EINVAL;
> + }
> + return 0;
> +
> +copy_out:
> + if (copy_to_user(arg, &ws, sizeof(ws)))
> + return -EFAULT;
> + return 0;
> +}
> +
> /*
> * These long-unused ioctls were removed from the official ioctl API in 5.17,
> * but retain these definitions so that we can log warnings about them.
> @@ -1425,6 +1457,8 @@ xfs_file_ioctl(
> return xfs_ioc_health_monitor(filp, arg);
> case XFS_IOC_VERIFY_MEDIA:
> return xfs_ioc_verify_media(filp, arg);
> + case FS_IOC_WRITE_STREAM:
> + return xfs_ioc_write_stream(filp, arg);
>
> default:
> return -ENOTTY;
> diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c
> index be86d43044df..7988c9e16635 100644
> --- a/fs/xfs/xfs_iomap.c
> +++ b/fs/xfs/xfs_iomap.c
> @@ -148,6 +148,7 @@ xfs_bmbt_to_iomap(
> else
> iomap->bdev = target->bt_bdev;
> iomap->flags = iomap_flags;
> + iomap->write_stream = ip->i_write_stream;
>
> /*
> * If the inode is dirty for datasync purposes, let iomap know so it
> --
> 2.25.1
>
>
next prev parent reply other threads:[~2026-03-09 16:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20260309053425epcas5p32886580a4fbe646ceee66f2864970e9f@epcas5p3.samsung.com>
2026-03-09 5:29 ` [PATCH v2 0/5] write streams and xfs spatial isolation Kanchan Joshi
2026-03-09 5:29 ` [PATCH v2 1/5] fs: add generic write-stream management ioctl Kanchan Joshi
2026-03-09 16:33 ` Darrick J. Wong
2026-03-10 17:55 ` Kanchan Joshi
2026-03-10 20:44 ` Darrick J. Wong
2026-03-09 5:29 ` [PATCH v2 2/5] iomap: introduce and propagate write_stream Kanchan Joshi
2026-03-09 16:34 ` Darrick J. Wong
2026-03-10 17:58 ` Kanchan Joshi
2026-03-09 5:29 ` [PATCH v2 3/5] xfs: implement write-stream management support Kanchan Joshi
2026-03-09 16:38 ` Darrick J. Wong [this message]
2026-03-10 18:07 ` Kanchan Joshi
2026-03-09 5:29 ` [PATCH v2 4/5] xfs: steer allocation using write stream Kanchan Joshi
2026-03-09 12:45 ` kernel test robot
2026-03-09 20:01 ` kernel test robot
2026-03-10 5:47 ` Dave Chinner
2026-03-10 19:03 ` Kanchan Joshi
2026-03-10 22:44 ` Dave Chinner
2026-03-11 9:59 ` Kanchan Joshi
2026-03-09 5:29 ` [PATCH v2 5/5] xfs: introduce software write streams Kanchan Joshi
2026-03-10 6:01 ` Dave Chinner
2026-03-09 15:40 ` [PATCH v2 0/5] write streams and xfs spatial isolation Christoph Hellwig
2026-03-10 21:19 ` Kanchan Joshi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260309163839.GG6033@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--cc=gost.dev@samsung.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=joshi.k@samsung.com \
--cc=kbusch@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.