Re: [PATCH 4/4] hfs: enable uncached buffer io support

[Viacheslav Dubeyko <slava@dubeyko.com>]

On Thu, 2025-06-26 at 11:30 -0600, Yangtao Li wrote:
> Now cont_write_begin() support DONTCACHE mode, let's set
> FOP_DONTCACHE
> flag to enable uncached buffer io support for hfs.
> 
> Signed-off-by: Yangtao Li <frank.li@vivo.com>
> ---
>  fs/hfs/inode.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/hfs/inode.c b/fs/hfs/inode.c
> index 8409e4412366..a62f45e9745d 100644
> --- a/fs/hfs/inode.c
> +++ b/fs/hfs/inode.c
> @@ -695,6 +695,7 @@ static const struct file_operations
> hfs_file_operations = {
>  	.fsync		= hfs_file_fsync,
>  	.open		= hfs_file_open,
>  	.release	= hfs_file_release,
> +	.fop_flags	= FOP_DONTCACHE,
>  };
>  
>  static const struct inode_operations hfs_file_inode_operations = {

Frankly speaking, I am not convinced that HFS really need to support
this feature. It is old and pretty obsolete file system. The main use-
case is simply support the capability to mount HFS volume is created
under Mac OS X, for example, and to access the data there. Of course,
we can support this feature, but what is the point of this?

As far as I can see, the goal of RWF_DONTCACHE feature is:

"Common for both reads and writes with RWF_DONTCACHE is that they use
the page cache for IO. Reads work just like a normal buffered read
would, with the only exception being that the touched ranges will get
pruned after data has been copied. For writes, the ranges will get
writeback kicked off before the syscall returns, and then writeback
completion will prune the range."

So, who would like to see such efficiency in HFS? Do we really need to
support it in HFS? I think that it is not.

Thanks,
Slava.