From: Hugh Dickins <hughd@google.com>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
Hugh Dickins <hughd@google.com>,
Christian Brauner <brauner@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Oleksandr Tymoshenko <ovt@google.com>,
Carlos Maiolino <cem@kernel.org>,
Jeff Layton <jlayton@kernel.org>,
Chuck Lever <chuck.lever@oracle.com>, Jan Kara <jack@suse.cz>,
Miklos Szeredi <miklos@szeredi.hu>, Daniel Xu <dxu@dxuuu.xyz>,
Chris Down <chris@chrisdown.name>, Tejun Heo <tj@kernel.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Matthew Wilcox <willy@infradead.org>,
Pete Zaitcev <zaitcev@redhat.com>, Helge Deller <deller@gmx.de>,
Topi Miettinen <toiwoton@gmail.com>,
Yu Kuai <yukuai3@huawei.com>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH vfs.tmpfs 4/5] tmpfs: trivial support for direct IO
Date: Thu, 10 Aug 2023 23:16:20 -0700 (PDT) [thread overview]
Message-ID: <5d913a4-a118-1218-25f2-32709b3e618@google.com> (raw)
In-Reply-To: <20230810234124.GH11336@frogsfrogsfrogs>
On Thu, 10 Aug 2023, Darrick J. Wong wrote:
> On Wed, Aug 09, 2023 at 06:41:17AM -0700, Christoph Hellwig wrote:
> > Please do not add a new ->direct_IO method. I'm currently working hard
> > on removing it, just set FMODE_CAN_ODIRECT and handle the fallback in
> > your read_iter/write_iter methods.
> >
> > But if we just start claiming direct I/O support for file systems that
> > don't actually support it, I'm starting to seriously wonder why we
> > bother with the flag at all and don't just allow O_DIRECT opens
> > to always succeed..
>
> I see it differently -- you can do byte-aligned directio to S_DAX files
> on persistent memory, so I don't see why you can't do that for tmpfs
> files too.
Helpful support, thanks. But I didn't read Christoph as unhappy with
the granularity issue: just giving me directIOn to FMODE_CAN_ODIRECT,
and rightly wondering why we ever fail O_DIRECTs.
Hugh
>
> (I'm not advocating for letting *disk* based filesystems allow O_DIRECT
> even if read and writes are always going to go through the page cache
> and get flushed to disk. If programs wanted that, they'd use O_SYNC.)
>
> /mnt is a pmem filesystem, /mnt/on/file has S_DAX set, and /mnt/off/file
> does not:
>
> # xfs_io -c statx /mnt/{on,off}/file
> fd.path = "/mnt/on/file"
> fd.flags = non-sync,non-direct,read-write
> stat.ino = 132
> stat.type = regular file
> stat.size = 1048576
> stat.blocks = 2048
> fsxattr.xflags = 0x8002 [-p------------x--]
> fsxattr.projid = 0
> fsxattr.extsize = 0
> fsxattr.cowextsize = 0
> fsxattr.nextents = 1
> fsxattr.naextents = 0
> dioattr.mem = 0x200
> dioattr.miniosz = 512
> dioattr.maxiosz = 2147483136
> fd.path = "/mnt/off/file"
> fd.flags = non-sync,non-direct,read-write
> stat.ino = 8388737
> stat.type = regular file
> stat.size = 1048576
> stat.blocks = 2048
> fsxattr.xflags = 0x2 [-p---------------]
> fsxattr.projid = 0
> fsxattr.extsize = 0
> fsxattr.cowextsize = 0
> fsxattr.nextents = 1
> fsxattr.naextents = 0
> dioattr.mem = 0x200
> dioattr.miniosz = 512
> dioattr.maxiosz = 2147483136
>
> And now we try a byte-aligned direct write:
>
> # xfs_io -d -c 'pwrite -S 0x58 47 1' /mnt/off/file
> pwrite: Invalid argument
> # xfs_io -d -c 'pwrite -S 0x58 47 1' /mnt/on/file
> wrote 1/1 bytes at offset 47
> 1.000000 bytes, 1 ops; 0.0001 sec (5.194 KiB/sec and 5319.1489 ops/sec)
>
> --D
next prev parent reply other threads:[~2023-08-11 6:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-09 4:28 [PATCH vfs.tmpfs 0/5] tmpfs: user xattrs and " Hugh Dickins
2023-08-09 4:30 ` [PATCH vfs.tmpfs 1/5] xattr: simple_xattr_set() return old_xattr to be freed Hugh Dickins
2023-08-09 9:21 ` Jan Kara
2023-08-09 11:37 ` Christian Brauner
2023-08-09 13:19 ` Carlos Maiolino
2023-08-09 4:32 ` [PATCH vfs.tmpfs 2/5] tmpfs: track free_ispace instead of free_inodes Hugh Dickins
2023-08-09 9:33 ` Jan Kara
2023-08-09 13:29 ` Carlos Maiolino
2023-08-09 4:33 ` [PATCH vfs.tmpfs 3/5] tmpfs,xattr: enable limited user extended attributes Hugh Dickins
2023-08-09 9:50 ` Jan Kara
2023-08-09 13:52 ` Carlos Maiolino
2023-08-09 4:34 ` [PATCH vfs.tmpfs 4/5] tmpfs: trivial support for direct IO Hugh Dickins
2023-08-09 9:54 ` Jan Kara
2023-08-09 13:41 ` Christoph Hellwig
2023-08-10 23:41 ` Darrick J. Wong
2023-08-11 6:16 ` Hugh Dickins [this message]
2023-08-11 8:34 ` Christoph Hellwig
2023-08-11 6:08 ` Hugh Dickins
2023-08-11 6:27 ` [PATCH vfs.tmpfs v2 " Hugh Dickins
2023-08-11 8:35 ` Christoph Hellwig
2023-08-11 8:56 ` Jan Kara
2023-08-11 11:00 ` (subset) " Christian Brauner
2023-08-09 4:36 ` [PATCH vfs.tmpfs 5/5] mm: invalidation check mapping before folio_contains Hugh Dickins
2023-08-09 9:27 ` Jan Kara
2023-08-09 6:45 ` [PATCH vfs.tmpfs 0/5] tmpfs: user xattrs and direct IO Christian Brauner
2023-08-09 11:33 ` Christian Brauner
2023-08-10 5:50 ` Hugh Dickins
2023-08-10 10:07 ` Christian Brauner
2023-08-21 17:39 ` [PATCH vfs.tmpfs] tmpfs,xattr: GFP_KERNEL_ACCOUNT for simple xattrs Hugh Dickins
2023-08-21 17:57 ` Jan Kara
2023-08-22 8:58 ` (subset) " Christian Brauner
2023-08-10 23:23 ` [PATCH vfs.tmpfs 0/5] tmpfs: user xattrs and direct IO Pete Zaitcev
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=5d913a4-a118-1218-25f2-32709b3e618@google.com \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=cem@kernel.org \
--cc=chris@chrisdown.name \
--cc=chuck.lever@oracle.com \
--cc=deller@gmx.de \
--cc=djwong@kernel.org \
--cc=dxu@dxuuu.xyz \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=jlayton@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=miklos@szeredi.hu \
--cc=ovt@google.com \
--cc=tj@kernel.org \
--cc=toiwoton@gmail.com \
--cc=willy@infradead.org \
--cc=yukuai3@huawei.com \
--cc=zaitcev@redhat.com \
/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