Date: Tue, 25 Apr 2023 15:27:37 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 271065] Kernel FUSE limits read() size by 64k/128k Message-ID: <bug-271065-227-KzVVdbGGRT@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-271065-227@https.bugs.freebsd.org/bugzilla/> References: <bug-271065-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271065 --- Comment #1 from Alan Somers <asomers@FreeBSD.org> --- If your userland program opens the file with O_DIRECT and tries to do large reads, what size of read does the server see? That should bypass the cache= .=20 I'm not saying that it's a permanent solution, but it might be a good experiment. The clustering and readahead code happens above the file system, up in the = VFS. It enters fuse in fuse_vnop_strategy. I'm a little rusty in that area, bu= t I think that you'll want to tweak settings so as to maximize the value of bp->b_bcount that the VFS sends in VOP_STRATEGY, rather than try to increase the size that we read from within there. You could try setting F_READAHEAD with fcntl, though I think it will still = be limited by maxphys. By doing that, I'm able to get sizes of 1 MB in VOP_STRATEGY. And you should certainly be setting -o async_read in the sshfs process. If you're planning to change the clustering code itself, you should definit= ely talk to mckusick. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271065-227-KzVVdbGGRT>