From owner-svn-src-all@freebsd.org Wed Feb 27 03:32:39 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 CCDCB150E4FB for ; Wed, 27 Feb 2019 03:32:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 687C689EF1 for ; Wed, 27 Feb 2019 03:32:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82c.google.com with SMTP id p48so17703412qtk.2 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=KJylP52UqcWt75Scc5xaVw5NVDtM6nzMr1CNwdo8qH7o/N5XMiRi7No6BqGpUsV7Sv WXUTzJ9YaNkOzs+8oszn+hmO0wb+auC8vN8mB8OaDqntK6Kpo7UW515SEEdfdhLWAYRs 2zM4la+Dtr4PxzoZvotRQF0JlSS6zdT8qYrKvPNi0/1x1guR21znqpoZaB53ncCrRGnq JbkDnfutu6sVxmM2mpsWeyRhNFFsboZL6vlEmTYW2dV0cELoVxVxk7Ma2Wsq2vSx34z4 O2dG1yWppXTe5CFbeLPb7Ae7VpwhVqTw1YlyrTTnhO5ElQgdtxmKvsKEldGjSpx9vFEf 5u9g== X-Gm-Message-State: APjAAAVwCzwkB0bJYe4dUxkcIQ9fCoF0Ts81FuLwckNhUTXqbL19JR1M DY7sJGO7w3/S3Bvh7rlErMjK/OlJDUp1dsODuLZI8g== 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: 687C689EF1 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" 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: 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 > >