Page MenuHomeFreeBSD

fusefs: forward the server's reported optimal transfer size to statfs
Needs ReviewPublic

Authored by asomers on Feb 12 2021, 3:41 AM.
Tags
None
Referenced Files
F82246415: D28607.diff
Fri, Apr 26, 10:38 PM
Unknown Object (File)
Mon, Apr 8, 2:50 AM
Unknown Object (File)
Mar 23 2024, 1:23 AM
Unknown Object (File)
Mar 19 2024, 2:21 AM
Unknown Object (File)
Mar 18 2024, 10:49 PM
Unknown Object (File)
Mar 18 2024, 11:51 AM
Unknown Object (File)
Feb 15 2024, 2:42 PM
Unknown Object (File)
Dec 20 2023, 6:32 AM
Subscribers

Details

Reviewers
cem
Summary

But don't report anything less than what we use for the buffer cache.

PR: 253424
Reported by: John Millikin <jmillikin@gmail.com>
MFC after: 1 week

Test Plan

Test cases added

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 36920
Build 33809: arc lint + arc unit

Event Timeline

sys/fs/fuse/fuse_vfsops.c
690–691

Does this make sense? I.e., should it just be f_iosize either way? Or should it be MIN()? I don't understand how iosize is used well enough, yet.

if iosize (aka maxbcachebuf) > fuse bsize: use larger maxbcachebuf for xfer efficiency
if iosize < fuse bsize: use smaller bcachebuf because it's the maximal bcache block size? Or does that not matter?

My guess is that these rarely conflict, but I don't know what the right thing to do at the edges is.

One thing we should verify is that f_iosize must be <= maxphys (see, e.g., kern/vfs_bio.c math for maxcl).

tests/sys/fs/fusefs/statfs.cc
211–215

As-written, I think this test would fail if vfs.macbcachebuf happened to be < 8192. I agree this is nonsense, but it's maybe worth calling out our environmental assumptions at least in a comment.