From owner-svn-src-all@freebsd.org Tue Feb 26 07:36:00 2019 Return-Path: Delivered-To: svn-src-all@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 E227D150EC34; Tue, 26 Feb 2019 07:35:59 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 5265970069; Tue, 26 Feb 2019 07:35:58 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id A546D4355D4; Tue, 26 Feb 2019 18:35:55 +1100 (AEDT) Date: Tue, 26 Feb 2019 18:35:54 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Jason Harmening cc: Bruce Evans , "Jason A. Harmening" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r344562 - head/sys/ufs/ffs In-Reply-To: <414d1964-f822-33f2-8177-872a4cbedd13@gmail.com> Message-ID: <20190226173749.A1863@besplex.bde.org> References: <201902260456.x1Q4uAIu056382@repo.freebsd.org> <20190226162300.M1437@besplex.bde.org> <414d1964-f822-33f2-8177-872a4cbedd13@gmail.com> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=nlC_4_pT8q9DhB4Ho9EA:9 a=Bi0UpnOnt1DyDkdv1HUA:9 a=45ClL6m2LaAA:10 X-Rspamd-Queue-Id: 5265970069 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.93 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.93)[-0.927,0] Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 07:36:00 -0000 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-all@freebsd.org Tue Feb 26 07:49:04 2019 Return-Path: Delivered-To: svn-src-all@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" 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 Date: Mon, 25 Feb 2019 23:49:01 -0800 (PST) CC: Jason Harmening , "Jason A. Harmening" , 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-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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