From owner-freebsd-fs@freebsd.org Wed Feb 20 23:10:27 2019 Return-Path: Delivered-To: freebsd-fs@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 C27A814E0569 for ; Wed, 20 Feb 2019 23:10:27 +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 5B0367435D for ; Wed, 20 Feb 2019 23:10:27 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 14D1A14E0568; Wed, 20 Feb 2019 23:10:27 +0000 (UTC) Delivered-To: fs@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 E4E5A14E0567 for ; Wed, 20 Feb 2019 23:10:26 +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.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 794F97435A for ; Wed, 20 Feb 2019 23:10:26 +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 BFB7213678 for ; Wed, 20 Feb 2019 23:10:25 +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 x1KNAP1L009859 for ; Wed, 20 Feb 2019 23:10:25 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x1KNAPpq009858 for fs@FreeBSD.org; Wed, 20 Feb 2019 23:10:25 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: fs@FreeBSD.org Subject: [Bug 230260] [FUSE] [PERFORMANCE]: Performance issue (I/O block size) Date: Wed, 20 Feb 2019 23:10:24 +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: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: fs@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-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2019 23:10:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230260 --- Comment #12 from Conrad Meyer --- (In reply to Kenneth D. Merry from comment #11) I think you're on to something. Are you on a recent head, or a stable bran= ch? It looks like fuse_write_biobackend directly uses f_iosize: 625 const int biosize =3D fuse_iosize(vp); but fuse_read_biobackend clamps the buf block len to MAXBSIZE: 191 const int biosize =3D fuse_iosize(vp); ... 201 bcount =3D MIN(MAXBSIZE, biosize); Which is defined as 64kB on CURRENT (i.e., the block size is not truncated = on bio read when DFLTPHYS <=3D MAXBSIZE). fuse's directio read path doesn't care about the freebsd block size or phys size and just issues maximal reads per the mount point. Ditto io_strategy, directio & bio write. So it's just the bio read path that is artificially truncating 512kB phys to 64kB MAXBSIZE. I think maxbcachebuf must be >=3D 512k on your system, too,= or else we'd trip this panic in getblk on write: 3883 if (size > maxbcachebuf) 3884 panic("getblk: size(%d) > maxbcachebuf(%d)\n", size, 3885 maxbcachebuf); (But perhaps the writes are hitting the directio write path that avoids the large getblk.) Anyway, once the blocks are truncated, the LBNs used by the cached read path are nonsensical relative to what was written, and we end up discarding the = last (DFLTPHYS - MAXBSIZE) bytes of every DFLTPHYS-sized block. I'm not exactly sure why the bioread loop aborts after only a single trunca= ted block. (I would guess either getblk() returning NULL on 2nd block, or getb= lk marking the 2nd block !CACHEd and fuse_io_strategy() producing an error for some reason.) I think we have a clear culprit here. Please try replacing f_iosize =3D DF= LTPHYS with f_iosize =3D MAXBSIZE or maxbcachebuf; or increasing MAXBSIZE to match DFLTPHYS. --=20 You are receiving this mail because: You are the assignee for the bug.=