From owner-freebsd-bugs@freebsd.org Thu Aug 2 05:01:06 2018 Return-Path: Delivered-To: freebsd-bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F51A105739C for ; Thu, 2 Aug 2018 05:01:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3CDE072AF6 for ; Thu, 2 Aug 2018 05:01:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 02106105739B; Thu, 2 Aug 2018 05:01:06 +0000 (UTC) Delivered-To: bugs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBD63105739A for ; Thu, 2 Aug 2018 05:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D69D72AF2 for ; Thu, 2 Aug 2018 05:01:05 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id ABD9723F1A for ; Thu, 2 Aug 2018 05:01:04 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w72514YF082042 for ; Thu, 2 Aug 2018 05:01:04 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w72514aS082038 for bugs@FreeBSD.org; Thu, 2 Aug 2018 05:01:04 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 230260] [FUSE] [PERFORMANCE]: Performance issue (I/O block size) Date: Thu, 02 Aug 2018 05:01:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: cem@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2018 05:01:06 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230260 --- Comment #4 from Conrad Meyer --- Doh, I totally missed some other hardcoded 4096 in the FUSE kernel support code. I see two instances: 1. fuse_internal_init_callback: if the fuse_init_out version is below 7.5, = we explicitly limit max_write to 4k. Otherwise we take max_write from the fii= o. 2. FUSE_DEFAULT_BLOCKSIZE , FUSE_DEFAULT_IOSIZE are both 4k. Supposedly bo= th can be overridden per mount, but given they are macro defines, I don't see = how that is possible. DEFAULT_IOSIZE is used to limit the size of FUSE_READDIR requests. It is a= lso a factor in limiting max_readahead (16x). DEFAULT_BLOCKSIZE is seemingly unused, except to fake FUSE_STATFS responses (f_bsize) if the user filesystem seems dead. I don't see either plumbed into ordinary read/write IO, though. PAGE_SIZE (also 4k) shows up a few times as well: 1. Internal caching of fuse file (vnode) attributes hardcodes va_blocksize = as PAGE_SIZE. I don't know the ramifications of this, if any. 2. Something around FUSE_READLINK operations restricts length to PAGE_SIZE.= =20 This doesn't seem like a problem. 3. fuse_vfsop_mount (VFS =3D operations on a filesystem, rather than on a specific file (vnode)) hardcodes mnt_stat.f_iosize as PAGE_SIZE. This may matter. It is the output of the fuse_iosize() function. 4. fuse_vnop_getpages walks through pages as part of the mmap interface. I don't think this is a problem. Ditto fuse_vnop_putpages. So yeah, (3) looks like it. fuse_iosize() is used as a direct limit in fuse_{read,write}_biobackend as well as fuse_io_strategy, and f_iosize is widely used throughout the generic kernel code. (It's also worth exploring bumping up the max READDIR size. That's probably not the problem you reported, but 4k is still anemic there.) --=20 You are receiving this mail because: You are the assignee for the bug.=