Linux filesystem development
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz,
	linux-fsdevel@vger.kernel.org, Dave Chinner <david@fromorbit.com>,
	Amir Goldstein <amir73il@gmail.com>
Subject: Re: [PATCH] fs: Add a new flag RWF_IOWAIT for preadv2(2)
Date: Mon, 5 Aug 2024 15:40:34 +0200	[thread overview]
Message-ID: <20240805134034.mf3ljesorgupe6e7@quack3> (raw)
In-Reply-To: <20240804080251.21239-1-laoar.shao@gmail.com>

On Sun 04-08-24 16:02:51, Yafang Shao wrote:
> Background
> ==========
> 
> Our big data workloads are deployed on XFS-based disks, and we frequently
> encounter hung tasks caused by xfs_ilock. These hung tasks arise because
> different applications may access the same files concurrently. For example,
> while a datanode task is writing to a file, a filebeat[0] task might be
> reading the same file concurrently. If the task writing to the file takes a
> long time, the task reading the file will hang due to contention on the XFS
> inode lock.
> 
> This inode lock contention between writing and reading files only occurs on
> XFS, but not on other file systems such as EXT4. Dave provided a clear
> explanation for why this occurs only on XFS[1]:
> 
>   : I/O is intended to be atomic to ordinary files and pipes and FIFOs.
>   : Atomic means that all the bytes from a single operation that started
>   : out together end up together, without interleaving from other I/O
>   : operations. [2]
>   : XFS is the only linux filesystem that provides this behaviour.
> 
> As we have been running big data on XFS for years, we don't want to switch
> to other file systems like EXT4. Therefore, we plan to resolve these issues
> within XFS.
> 
> Proposal
> ========
> 
> One solution we're currently exploring is leveraging the preadv2(2)
> syscall. By using the RWF_NOWAIT flag, preadv2(2) can avoid the XFS inode
> lock hung task. This can be illustrated as follows:
> 
>   retry:
>       if (preadv2(fd, iovec, cnt, offset, RWF_NOWAIT) < 0) {
>           sleep(n)
>           goto retry;
>       }
> 
> Since the tasks reading the same files are not critical tasks, a delay in
> reading is acceptable. However, RWF_NOWAIT not only enables IOCB_NOWAIT but
> also enables IOCB_NOIO. Therefore, if the file is not in the page cache, it
> will loop indefinitely until someone else reads it from disk, which is not
> acceptable.
> 
> So we're planning to introduce a new flag, IOCB_IOWAIT, to preadv2(2). This
> flag will allow reading from the disk if the file is not in the page cache
> but will not allow waiting for the lock if it is held by others. With this
> new flag, we can resolve our issues effectively.
> 
> Link: https://lore.kernel.org/linux-xfs/20190325001044.GA23020@dastard/ [0]
> Link: https://github.com/elastic/beats/tree/master/filebeat [1]
> Link: https://pubs.opengroup.org/onlinepubs/009695399/functions/read.html [2]
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> Cc: Dave Chinner <david@fromorbit.com>

Thanks for the detailed explanation! I understand your problem but I have to
say I find this flag like a hack to workaround particular XFS behavior and
the guarantees the new RWF_IOWAIT flag should provide are not very clear to
me. I've CCed Amir who's been dealing with similar issues with XFS at his
employer and had some patches as far as I remember.

What you could possibly do to read the file contents without blocking on
xfs_iolock is to mmap the file and grab the data from the mapping. It is
still hacky but at least we don't have to pollute the kernel with an IO
flag with unclear semantics.

								Honza

> ---
>  include/linux/fs.h      | 6 ++++++
>  include/uapi/linux/fs.h | 5 ++++-
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index fd34b5755c0b..5df7b5b0927a 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -3472,6 +3472,12 @@ static inline int kiocb_set_rw_flags(struct kiocb *ki, rwf_t flags,
>  			return -EPERM;
>  		ki->ki_flags &= ~IOCB_APPEND;
>  	}
> +	if (flags & RWF_IOWAIT) {
> +		kiocb_flags |= IOCB_NOWAIT;
> +		/* IOCB_NOIO is not allowed for RWF_IOWAIT */
> +		if (kiocb_flags & IOCB_NOIO)
> +			return -EINVAL;
> +	}
>  
>  	ki->ki_flags |= kiocb_flags;
>  	return 0;
> diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
> index 191a7e88a8ab..17a8c065d636 100644
> --- a/include/uapi/linux/fs.h
> +++ b/include/uapi/linux/fs.h
> @@ -332,9 +332,12 @@ typedef int __bitwise __kernel_rwf_t;
>  /* Atomic Write */
>  #define RWF_ATOMIC	((__force __kernel_rwf_t)0x00000040)
>  
> +/* per-IO, allow waiting for IO, but not waiting for lock */
> +#define RWF_IOWAIT	((__force __kernel_rwf_t)0x00000080)
> +
>  /* mask of flags supported by the kernel */
>  #define RWF_SUPPORTED	(RWF_HIPRI | RWF_DSYNC | RWF_SYNC | RWF_NOWAIT |\
> -			 RWF_APPEND | RWF_NOAPPEND | RWF_ATOMIC)
> +			 RWF_APPEND | RWF_NOAPPEND | RWF_ATOMIC | RWF_IOWAIT)
>  
>  /* Pagemap ioctl */
>  #define PAGEMAP_SCAN	_IOWR('f', 16, struct pm_scan_arg)
> -- 
> 2.43.5
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  reply	other threads:[~2024-08-05 13:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-04  8:02 [PATCH] fs: Add a new flag RWF_IOWAIT for preadv2(2) Yafang Shao
2024-08-05 13:40 ` Jan Kara [this message]
2024-08-05 14:07   ` Christian Brauner
2024-08-06 11:54   ` Yafang Shao
2024-08-06 13:24     ` Jan Kara
2024-08-06 14:05       ` Yafang Shao
2024-08-06 21:52         ` Dave Chinner
2024-08-07  3:01           ` Yafang Shao
2024-08-08  2:51             ` Dave Chinner
2024-08-08 13:16               ` Yafang Shao
2024-08-06 14:57       ` Christian Brauner
2024-08-06  5:47 ` Dave Chinner
2024-08-06 11:44   ` Yafang Shao
2024-08-06 15:08 ` Matthew Wilcox
2024-08-07  2:29   ` Yafang Shao

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=20240805134034.mf3ljesorgupe6e7@quack3 \
    --to=jack@suse.cz \
    --cc=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=david@fromorbit.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox