From owner-svn-src-head@freebsd.org Wed Feb 27 03:32:40 2019 Return-Path: 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 1DDD7150E4FD for ; Wed, 27 Feb 2019 03:32:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AE34989EF3 for ; Wed, 27 Feb 2019 03:32:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82e.google.com with SMTP id u7so8465177qtg.9 for ; Tue, 26 Feb 2019 19:32:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jFXkU9Tg+C04zVlgmvvRMp9aLDxmmoxHwec7zAEroi8=; b=xosrBUpbvziYuwWF5ZzOI82pO0u1mvmc8bg9b2L6vcLTg3S7RWHuSFa1N9ur21MwL4 dl2R/Ykl6H6H2jB0CzyjTy3nIaBnzM/E5/U5BNGeyBy1rFof28K+0bh8w/GFTe4YnoV/ KsxpIDLeX01zeSXYTXN7pOSqVKXBcQaErngRXb90ZXh0Bltuh3P1IgI9zzMb1YmVeQTJ NVXoHNZm4Z7oA39z5eMm7ceS0iRvF9UKkgKlAB/EZD9eAQaAtForHXDs3ueInPe3jVY2 hWUGUhC5BI/XUKgVrzFgT4xhbh+rcUx76GVwavBnd5yaQKCULqGayI3VPZaWnLULka8W 7E+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jFXkU9Tg+C04zVlgmvvRMp9aLDxmmoxHwec7zAEroi8=; b=klpmMLWF1XaRao+K6Vgx5tzL1dNDRqEGoA9mqxq6xzt3d70cjh5BuDQMGYCiwQplMP XB5TE09rTTyCoF7rds2RLUfnlimBfeOpBtnIeILdZ74gUOaq783BSGLX7Tui5mAzP6Ft A/trIgmiFGlzrVQj7CGjNefyxmQvjQ7mCG7RbMDPcjL7NPXi59KjIVd6M0bo+saVoEk9 VqR0Sm8C97GK7l+8NmhR8AkByiZMiOwGB+QCf1JymusUgJFMS79t/7MlBOI4NjTCw3fF U/J6lIBynSATpWyk3kL17l3bCrw1JJ5DrQibJKwsAk+2seUamWw8rnGtEgjKUAbEsS55 aoBA== X-Gm-Message-State: APjAAAUS47e2qv5WshHP3zacbSIMk+zoNegLw67hhrYflsg3DD3VXvH8 nne5dABGiE8ya3+/ULHSVXsaV6zYdLAElUFRjDct/w== X-Google-Smtp-Source: APXvYqwaTjVdMyfIMgSvzL3hZuiYgXDZNVfzq3zYOZIBGOjTiE4s3owQSgZukaNxp1m+UAzhleBOLidnNR7Bau2zlKE= X-Received: by 2002:a0c:987a:: with SMTP id e55mr219396qvd.21.1551238358844; Tue, 26 Feb 2019 19:32:38 -0800 (PST) MIME-Version: 1.0 References: <20190226173749.A1863@besplex.bde.org> <201902260749.x1Q7n1GI043756@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201902260749.x1Q7n1GI043756@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 26 Feb 2019 20:32:26 -0700 Message-ID: Subject: Re: svn commit: r344562 - head/sys/ufs/ffs To: "Rodney W. Grimes" Cc: Bruce Evans , Jason Harmening , "Jason A. Harmening" , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org X-Rspamd-Queue-Id: AE34989EF3 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2019 03:32:40 -0000 On Tue, Feb 26, 2019, 12:49 AM Rodney W. Grimes < freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > 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. > There are a number of drives that report 16k physical, but 4k sector size. Others vendors have suggested that 32k or 64k may be on the horizon. But all these drives still report an LBA size of 4k. The drive vendors I've talked to have indicated that a larger sector size is in the works, but so far they haven't indicated what that newer size will wind up being, or when it would appear in the market... The timing of when may be unknown, but it's quite likely the future will have to cope with a mismatch. Warner > 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 > >