Date: Thu, 21 Feb 2019 16:44:22 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 230260] [FUSE] [PERFORMANCE]: Performance issue (I/O block size) Message-ID: <bug-230260-3630-IC1rvawEAA@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230260-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-230260-3630@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=3D230260 --- Comment #15 from Conrad Meyer <cem@freebsd.org> --- (In reply to Kenneth D. Merry from comment #14) I don't do stable/, but anyone is free to MFC it themselves. It shouldn't conflict. > Since tape drives don't do tagged queueing, the common way to get better > performance is to use a larger block size. LTFS supports up to 1MB block > sizes, and in order to read tapes from other systems and get better > performance, we set MAXPHYS to over 1MB. (So we can get 1MB I/O regardle= ss > of alignment.) DFLTPHYS goes along with that. Yeah, that makes a lot of sense. (I think it is probable that FUSE should move to the tunable maxbcachebuf instead of MAXBSIZE; MAXBSIZE is nearly orphaned in base, and can probably = be removed. But that is somewhat orthogonal.) Thank you for reporting this and especially mentioning the non-default DFLTPHYS. I did not realize it was a value people changed in their own kernels. :-) --=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-230260-3630-IC1rvawEAA>