From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Christoph Hellwig <hch@lst.de>, tytso@mit.edu
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH] ext4: set FMODE_CAN_ODIRECT instead of a dummy direct_IO method
Date: Tue, 13 Jun 2023 11:00:19 +0530 [thread overview]
Message-ID: <87wn0853pw.fsf@doe.com> (raw)
In-Reply-To: <20230612053731.585947-1-hch@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> Since commit a2ad63daa88b ("VFS: add FMODE_CAN_ODIRECT file flag") file
> systems can just set the FMODE_CAN_ODIRECT flag at open time instead of
> wiring up a dummy direct_IO method to indicate support for direct I/O.
>
> Do that for ext4 so that noop_direct_IO can eventually be removed.
Looks straight forward change to me.
However I got some query...
> diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
> index 02de439bf1f04e..b9c1cfa1864779 100644
> --- a/fs/ext4/inode.c
> +++ b/fs/ext4/inode.c
> @@ -3573,7 +3571,6 @@ static const struct address_space_operations ext4_da_aops = {
> .bmap = ext4_bmap,
> .invalidate_folio = ext4_invalidate_folio,
> .release_folio = ext4_release_folio,
> - .direct_IO = noop_direct_IO,
> .migrate_folio = buffer_migrate_folio,
> .is_partially_uptodate = block_is_partially_uptodate,
> .error_remove_page = generic_error_remove_page,
> @@ -3582,7 +3579,6 @@ static const struct address_space_operations ext4_da_aops = {
>
> static const struct address_space_operations ext4_dax_aops = {
> .writepages = ext4_dax_writepages,
> - .direct_IO = noop_direct_IO,
> .dirty_folio = noop_dirty_folio,
> .bmap = ext4_bmap,
> .swap_activate = ext4_iomap_swap_activate,
why do we require .direct_IO function op for any of the dax_aops?
IIUC, any inode if it supports DAX i.e. IS_DAX(inode), then it takes the
separate path in file read/write iter path.
so it should never do ->direct_IO on an inode which supports DAX right?
Maybe I am missing something and I will have to check when does
->direct_IO gets called for DAX...
... Or is it due to CONFIG_FS_DAX?
e.g.
ext4_file_write_iter(struct kiocb *iocb, struct iov_iter *from)
{
struct inode *inode = file_inode(iocb->ki_filp);
if (unlikely(ext4_forced_shutdown(EXT4_SB(inode->i_sb))))
return -EIO;
#ifdef CONFIG_FS_DAX
if (IS_DAX(inode))
return ext4_dax_write_iter(iocb, from);
#endif
if (iocb->ki_flags & IOCB_DIRECT)
return ext4_dio_write_iter(iocb, from);
else
return ext4_buffered_write_iter(iocb, from);
}
-ritesh
next prev parent reply other threads:[~2023-06-13 5:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-12 5:37 [PATCH] ext4: set FMODE_CAN_ODIRECT instead of a dummy direct_IO method Christoph Hellwig
2023-06-13 5:30 ` Ritesh Harjani [this message]
2023-06-13 5:47 ` Christoph Hellwig
2023-06-13 13:57 ` Ritesh Harjani
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=87wn0853pw.fsf@doe.com \
--to=ritesh.list@gmail.com \
--cc=hch@lst.de \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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.