[RFC PATCH 0/3] 9p: Further netfslib-related changes

[RFC PATCH 0/3] 9p: Further netfslib-related changes

[David Howells]

Hi Eric, Dominique,

Here are some netfslib-related changes we might want to consider applying
to 9p:

 (1) Enable large folio support for 9p.  This is handled entirely by
     netfslib and is already supported in afs.  I wonder if we should limit
     the maximum folio size to 1MiB to match the maximum I/O size in the 9p
     protocol.

 (2) Make better use of netfslib's writethrough caching support by not
     disabling caching for O_DSYNC.  netfs_perform_write() will set up
     and dispatch write requests as it copies data into the pagecache.

 (3) Always update netfs_inode::remote_size to reflect what we think the
     server's idea of the file size is.  This is separate from
     inode::i_size which is our idea of what it should be if all of our
     outstanding dirty data is committed.

The patches can also be found here:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=netfs-9p

Thanks,
David

David Howells (2):
  9p: Make better use of netfslib's writethrough caching
  9p: Always update remote_i_size in stat2inode

Dominique Martinet (1):
  9p: Enable large folio support

 fs/9p/fid.h            | 3 +--
 fs/9p/vfs_inode.c      | 1 +
 fs/9p/vfs_inode_dotl.c | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

[RFC PATCH 1/3] 9p: Enable large folio support

[David Howells]

From: Dominique Martinet <asmadeus@codewreck.org>

Enable large folio support in 9P now that the VM/VFS data I/O interface is
handled through netfslib.

Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Van Hensbergen <ericvh@kernel.org>
cc: Latchesar Ionkov <lucho@ionkov.net>
cc: Dominique Martinet <asmadeus@codewreck.org>
cc: Christian Schoenebeck <linux_oss@crudebyte.com>
cc: Matthew Wilcox <willy@infradead.org>
cc: v9fs@lists.linux.dev
cc: netfs@lists.linux.dev
---
 fs/9p/vfs_inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/9p/vfs_inode.c b/fs/9p/vfs_inode.c
index 32572982f72e..ca9f504b9daf 100644
--- a/fs/9p/vfs_inode.c
+++ b/fs/9p/vfs_inode.c
@@ -262,6 +262,7 @@ int v9fs_init_inode(struct v9fs_session_info *v9ses,
 	inode->i_rdev = rdev;
 	simple_inode_init_ts(inode);
 	inode->i_mapping->a_ops = &v9fs_addr_operations;
+	mapping_set_large_folios(inode->i_mapping);
 	inode->i_private = NULL;
 
 	switch (mode & S_IFMT) {

[RFC PATCH 2/3] 9p: Make better use of netfslib's writethrough caching

[David Howells]

netfslib offers the opportunity to do a form of writethrough caching on the
pagecache, whereby netfs_perform_write() will set up and dispatch writes to
the network as it copies data into the cache, falling back to the ordinary
writeback path for the dirty data if this fails.  This is selected if the
user sets O_DSYNC, O_SYNC, RWF_DSYNC or RWF_SYNC or if the filesystem sets
NETFS_ICTX_WRITETHROUGH.

Change v9fs_fid_add_modes() to use this if O_DSYNC is set - and assuming
that CACHE_WRITEBACK is set and V9FS_SYNC is not set.

[?] Does it make sense to add an additional caching mode that uses
    write-through for all non-DIO writes?

Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Van Hensbergen <ericvh@kernel.org>
cc: Latchesar Ionkov <lucho@ionkov.net>
cc: Dominique Martinet <asmadeus@codewreck.org>
cc: Christian Schoenebeck <linux_oss@crudebyte.com>
cc: Jeff Layton <jlayton@kernel.org>
cc: v9fs@lists.linux.dev
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org
---
 fs/9p/fid.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/fs/9p/fid.h b/fs/9p/fid.h
index 29281b7c3887..0b25b4c9781d 100644
--- a/fs/9p/fid.h
+++ b/fs/9p/fid.h
@@ -56,8 +56,7 @@ static inline void v9fs_fid_add_modes(struct p9_fid *fid, unsigned int s_flags,
 	   ((fid->qid.version == 0) && !(s_flags & V9FS_IGNORE_QV)) ||
 	   (s_flags & V9FS_DIRECT_IO) || (f_flags & O_DIRECT)) {
 		fid->mode |= P9L_DIRECT; /* no read or write cache */
-	} else if ((!(s_cache & CACHE_WRITEBACK)) ||
-				(f_flags & O_DSYNC) || (s_flags & V9FS_SYNC)) {
+	} else if ((!(s_cache & CACHE_WRITEBACK)) || (s_flags & V9FS_SYNC)) {
 		fid->mode |= P9L_NOWRITECACHE;
 	}
 }

[RFC PATCH 3/3] 9p: Always update remote_i_size in stat2inode

[David Howells]

Always update remote_i_size in v9fs_stat2inode*() if the size is available,
even if we are asked not to update i_isize

Suggested-by: Dominique Martinet <asmadeus@codewreck.org>
Link: https://lore.kernel.org/r/ZZVctju5TEjS218p@codewreck.org/
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Eric Van Hensbergen <ericvh@kernel.org>
cc: Latchesar Ionkov <lucho@ionkov.net>
cc: Christian Schoenebeck <linux_oss@crudebyte.com>
cc: v9fs@lists.linux.dev
cc: linux-cachefs@redhat.com
cc: linux-fsdevel@vger.kernel.org
---
 fs/9p/vfs_inode_dotl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/9p/vfs_inode_dotl.c b/fs/9p/vfs_inode_dotl.c
index 3505227e1704..aa3a77bb5e86 100644
--- a/fs/9p/vfs_inode_dotl.c
+++ b/fs/9p/vfs_inode_dotl.c
@@ -684,10 +684,10 @@ v9fs_stat2inode_dotl(struct p9_stat_dotl *stat, struct inode *inode,
 			mode |= inode->i_mode & ~S_IALLUGO;
 			inode->i_mode = mode;
 		}
-		if (!(flags & V9FS_STAT2INODE_KEEP_ISIZE) &&
-		    stat->st_result_mask & P9_STATS_SIZE) {
+		if (stat->st_result_mask & P9_STATS_SIZE) {
 			v9inode->netfs.remote_i_size = stat->st_size;
-			v9fs_i_size_write(inode, stat->st_size);
+			if (!(flags & V9FS_STAT2INODE_KEEP_ISIZE))
+				v9fs_i_size_write(inode, stat->st_size);
 		}
 		if (stat->st_result_mask & P9_STATS_BLOCKS)
 			inode->i_blocks = stat->st_blocks;

Re: [RFC PATCH 0/3] 9p: Further netfslib-related changes

[Christian Schoenebeck]

On Monday, January 29, 2024 12:54:34 PM CET David Howells wrote:
> Hi Eric, Dominique,
> 
> Here are some netfslib-related changes we might want to consider applying
> to 9p:
> 
>  (1) Enable large folio support for 9p.  This is handled entirely by
>      netfslib and is already supported in afs.  I wonder if we should limit
>      the maximum folio size to 1MiB to match the maximum I/O size in the 9p
>      protocol.

The limit depends on user's 'msize' 9p client option and on the 9p transport
implementation. The hard limit with virtio transport for instance is currently
just 500k (patches for virtio 4MB limit fetching dust unfortunately).

Would you see an advantage to limit folio size? I mean p9_client_read() etc.
are automatically limiting the read/write chunk size accordingly.

>  (2) Make better use of netfslib's writethrough caching support by not
>      disabling caching for O_DSYNC.  netfs_perform_write() will set up
>      and dispatch write requests as it copies data into the pagecache.
> 
>  (3) Always update netfs_inode::remote_size to reflect what we think the
>      server's idea of the file size is.  This is separate from
>      inode::i_size which is our idea of what it should be if all of our
>      outstanding dirty data is committed.
> 
> The patches can also be found here:
> 
> 	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=netfs-9p
> 
> Thanks,
> David
> 
> David Howells (2):
>   9p: Make better use of netfslib's writethrough caching
>   9p: Always update remote_i_size in stat2inode
> 
> Dominique Martinet (1):
>   9p: Enable large folio support
> 
>  fs/9p/fid.h            | 3 +--
>  fs/9p/vfs_inode.c      | 1 +
>  fs/9p/vfs_inode_dotl.c | 6 +++---
>  3 files changed, 5 insertions(+), 5 deletions(-)

Re: [RFC PATCH 0/3] 9p: Further netfslib-related changes

[David Howells]

Christian Schoenebeck <linux_oss@crudebyte.com> wrote:

> >  (1) Enable large folio support for 9p.  This is handled entirely by
> >      netfslib and is already supported in afs.  I wonder if we should limit
> >      the maximum folio size to 1MiB to match the maximum I/O size in the 9p
> >      protocol.
> 
> The limit depends on user's 'msize' 9p client option and on the 9p transport
> implementation. The hard limit with virtio transport for instance is currently
> just 500k (patches for virtio 4MB limit fetching dust unfortunately).

Okay.  Is that 500KiB or 512Kib?

> Would you see an advantage to limit folio size? I mean p9_client_read() etc.
> are automatically limiting the read/write chunk size accordingly.

For reads not so much, but for writes it would mean that a dirty folio is
either entirely written or entirely failed.  I don't know how important this
would be for the 9p usecases.

David

Re: [RFC PATCH 0/3] 9p: Further netfslib-related changes

[Christian Schoenebeck]

On Monday, January 29, 2024 3:22:15 PM CET David Howells wrote:
> Christian Schoenebeck <linux_oss@crudebyte.com> wrote:
> 
> > >  (1) Enable large folio support for 9p.  This is handled entirely by
> > >      netfslib and is already supported in afs.  I wonder if we should limit
> > >      the maximum folio size to 1MiB to match the maximum I/O size in the 9p
> > >      protocol.
> > 
> > The limit depends on user's 'msize' 9p client option and on the 9p transport
> > implementation. The hard limit with virtio transport for instance is currently
> > just 500k (patches for virtio 4MB limit fetching dust unfortunately).
> 
> Okay.  Is that 500KiB or 512Kib?

'msize' is currently hard limited by virtio transport to exactly 512000. For
rdma and fd transports it's both exactly 1MiB. For xen transport it should be
exactly 524288 (could be lowered though depending on configured xen ring
size). You find the individual transports to fill the field 'maxsize'
accordingly (in net/9p/trans_*.c).

So that's the maximum message size. Then the individual 9p message header
size needs to be subtracted. For Twrite request that's -23, for Rread
response that's -11.

> > Would you see an advantage to limit folio size? I mean p9_client_read() etc.
> > are automatically limiting the read/write chunk size accordingly.
> 
> For reads not so much, but for writes it would mean that a dirty folio is
> either entirely written or entirely failed.  I don't know how important this
> would be for the 9p usecases.
> 
> David
> 
>