Date: Tue, 26 Feb 2019 18:35:54 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jason Harmening <jason.harmening@gmail.com> Cc: Bruce Evans <brde@optusnet.com.au>, "Jason A. Harmening" <jah@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r344562 - head/sys/ufs/ffs Message-ID: <20190226173749.A1863@besplex.bde.org> In-Reply-To: <414d1964-f822-33f2-8177-872a4cbedd13@gmail.com> References: <201902260456.x1Q4uAIu056382@repo.freebsd.org> <20190226162300.M1437@besplex.bde.org> <414d1964-f822-33f2-8177-872a4cbedd13@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 25 Feb 2019, Jason Harmening wrote: > On 2/25/19 9:46 PM, Bruce Evans wrote: >>=20 >> block_size <=3D PAGE_SIZE is very uncommon for ffs, even on systems with= =20 >> large >> pages.=C2=A0 MINBSIZE is 4096 in ffs (except in my version, it is 512).= =C2=A0 The >> default is 32768 in newfs.=C2=A0 I consider this excessive and only use = it for >> file systems with many files larger than 1GB, but it is the most common= =20 >> size. >> It is larger than the large page size of 8192. > > I think this is a case of filesystem logical block size vs. media sector= =20 > size, right? Here we're checking the devvp's block size, which I think= =20 > should correspond to the sector size. I'd expect cases of that being > greater than PAGE_SIZE to be uncommon, in fact geli warns when that is th= e=20 > case. I probably should've made that clearer in the commit message. Yes, I missed that you are checking devvp. ffs_getpages() also checks devvp. So the bug has nothing to do with file system logical (fragment) or i/o (block) block size's, except file systems themselves won't work unless their i/o size is a multiple of the underlying devices (sector) i/o size. Are there physical disk with sector size > PAGE_SIZE now? It is easy to create virtual (md) disks with sector size > PAGE_SIZE, and this may even be useful for avoiding the related problem of having to access large fs blocks to do i/o to small md sectors. I think it is best to use PAGE_SIZE blocks in all layers and sometimes combine these into clusters. Bruce From owner-svn-src-head@freebsd.org Tue Feb 26 07:49:04 2019 Return-Path: <owner-svn-src-head@freebsd.org> Delivered-To: svn-src-head@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 076C7150F756; Tue, 26 Feb 2019 07:49:04 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 65D5370A4D; Tue, 26 Feb 2019 07:49:03 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x1Q7n1Ah043757; Mon, 25 Feb 2019 23:49:01 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x1Q7n1GI043756; Mon, 25 Feb 2019 23:49:01 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> Message-Id: <201902260749.x1Q7n1GI043756@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r344562 - head/sys/ufs/ffs In-Reply-To: <20190226173749.A1863@besplex.bde.org> To: Bruce Evans <brde@optusnet.com.au> Date: Mon, 25 Feb 2019 23:49:01 -0800 (PST) CC: Jason Harmening <jason.harmening@gmail.com>, "Jason A. Harmening" <jah@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UNKNOWN-8BIT X-Rspamd-Queue-Id: 65D5370A4D X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.972,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/>; List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 26 Feb 2019 07:49:04 -0000 > On Mon, 25 Feb 2019, Jason Harmening wrote: > > > On 2/25/19 9:46 PM, Bruce Evans wrote: > >> > >> block_size <= PAGE_SIZE is very uncommon for ffs, even on systems with > >> large > >> pages. MINBSIZE is 4096 in ffs (except in my version, it is 512). The > >> default is 32768 in newfs. I consider this excessive and only use it for > >> file systems with many files larger than 1GB, but it is the most common > >> size. > >> It is larger than the large page size of 8192. > > > > I think this is a case of filesystem logical block size vs. media sector > > size, right? Here we're checking the devvp's block size, which I think > > should correspond to the sector size. I'd expect cases of that being > > greater than PAGE_SIZE to be uncommon, in fact geli warns when that is the > > case. I probably should've made that clearer in the commit message. > > Yes, I missed that you are checking devvp. ffs_getpages() also checks > devvp. > > So the bug has nothing to do with file system logical (fragment) or i/o > (block) block size's, except file systems themselves won't work unless > their i/o size is a multiple of the underlying devices (sector) i/o size. > > Are there physical disk with sector size > PAGE_SIZE now? I have been told that there are some sd/flash devices that have a 16k physical sector size, I have not been able to confirm that information though. > It is easy to > create virtual (md) disks with sector size > PAGE_SIZE, and this may even > be useful for avoiding the related problem of having to access large fs > blocks to do i/o to small md sectors. I think it is best to use PAGE_SIZE > blocks in all layers and sometimes combine these into clusters. > > Bruce -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190226173749.A1863>