From owner-svn-src-head@freebsd.org Fri Oct 16 19:24:27 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CBAAEA16B06 for ; Fri, 16 Oct 2015 19:24:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9F40A25D for ; Fri, 16 Oct 2015 19:24:27 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by pacfv9 with SMTP id fv9so30683954pac.3 for ; Fri, 16 Oct 2015 12:24:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=1Sq0m/R9vp55uy+rIbhke/MMPkti2g8pFx6VFfC742c=; b=KtKCprFwUm3cL5lJJ0sKe6l/eOsbSbE9WFu+ql0vuk1jpXTws5Y2RgD5wcpvlwY0NK lrYiwo+TTLwlWDHihHJt2FW/6Z2yORIAVYlN2LrBKvyonRsVA4Fs4qX44VpXaAO8VB9Y smv/iwu5ip7NT6rku1ng4Nuv2tuj4dSl7B9bvuHrmvRBcshPtv8pNJHDFXiSSLbwBko0 QoaV7rzJSzi7psNlIiPYAGkWI3eSEy7hzvna3xPpqqi19qURQzotPohSrwF0FvHMfL+m RVfl12Lff4u1FeydXp5qnTXZbxNLU+xwhqa/2iTpiI65bw29LY1xos5fxywgr7i/mmvt peKw== X-Gm-Message-State: ALoCoQk/e8DxdweCVhbRl98ysH8Btw1UH48cfsENflRbnwjTQswsoqnylyrUbzAWn38cYzB/nY9o X-Received: by 10.67.30.136 with SMTP id ke8mr18617677pad.16.1445023467112; Fri, 16 Oct 2015 12:24:27 -0700 (PDT) Received: from ip-100-127-144-209.ec2.internal ([69.53.245.40]) by smtp.gmail.com with ESMTPSA id ix1sm9386977pbd.40.2015.10.16.12.24.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 16 Oct 2015 12:24:26 -0700 (PDT) Sender: Warner Losh Subject: Re: svn commit: r289405 - head/sys/ufs/ffs Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A61B5B61-D22A-4A4C-9A17-34CDD74809B4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <562103B6.2090406@FreeBSD.org> Date: Fri, 16 Oct 2015 13:24:22 -0600 Cc: Bruce Evans , Hans Petter Selasky , Warner Losh , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Message-Id: References: <201510160306.t9G3622O049128@repo.freebsd.org> <20151016151349.W1280@besplex.bde.org> <5620B15C.8090104@selasky.org> <20151016194242.N2138@besplex.bde.org> <562103B6.2090406@FreeBSD.org> To: Pedro Giffuni X-Mailer: Apple Mail (2.2104) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 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: Fri, 16 Oct 2015 19:24:27 -0000 --Apple-Mail=_A61B5B61-D22A-4A4C-9A17-34CDD74809B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Oct 16, 2015, at 8:03 AM, Pedro Giffuni wrote: >=20 >=20 >=20 > On 10/16/15 03:53, Bruce Evans wrote: >> On Fri, 16 Oct 2015, Hans Petter Selasky wrote: >>=20 >>> On 10/16/15 08:21, Bruce Evans wrote: >>>> [Bruce Evans didn't write:] >>>> In addition, making the file contiguous in LBA space doesn't >>>> improve the access times from flash devices because they have no = seek >>>> time. >>>=20 >>> This is not exactly true, like Bruce pointed out too. Maybe there >>> should be a check, that if the block is too small reallocate it, = else >>> leave it for the sake of the flash. Doing 1K accesses versus 64K >>> accesses will typically show up in the performance benchmark >>> regardless of how fast the underlying medium is. >>=20 >> Now I don't unerstand the whole point of the change. Anything that = reduces >> i/o's is good, but AFAIK ffs_doreallocblks() is all in software. = Writes >> should be delayed so that it doesn't have to do extra i/o's to back = out of >> committed writes. Often it reduces the number of writes and = increases >> their size by making blocks contiguous so that the write can be = clustered. >> Increasing the write size is especially good for flash devices, but = maybe >> ffs's default block size is already large enough. >>=20 >=20 > I agree with Bruce: reallocation (which our ext2fs also does) happens > in memory, before it hits the disk. >=20 > By the nature of their load, Netflix doesn't care about fragmentation, > but even in that case reallocblk doesn't hurt, and I don't see = anything > inherent in SSDs that makes fragmentation desirable. >=20 > Of course, no one understands reallocblk better than Kirk, and Warner > knows SSD's pretty well so I must be missing something. :). This has nothing to do with fragments at all. This is all about = rearranging FFS blocks arbitrarily, which isn=92t all in memory before the writes = happen. The data can and does move, which generates TRIM operations for the old data placement, and real writes for the new data placement. = These optimizations do help. Warner --Apple-Mail=_A61B5B61-D22A-4A4C-9A17-34CDD74809B4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWIU7mAAoJEGwc0Sh9sBEAfWMQAKSJFNG5G3FJ5eOJKtCJGuOE hLc9ZSny6vHGHk8RuqgWJBgESh2VaocOwewkCB2wdbHCCk0vH3OuRflb6zviH0jI fAFyVpiCGqWJ6hkap57xHfwU+a9iHgY0wT2cHCyh1M3sOC03KqGa31UnZcZ1detF 2JtKewPE+KvAL09KbjLkpEmBESrWIMf0ABiL/KFa2sUSR9P8SvwA55AmymU67Zjc 52VLeiSwoBheYhL6fSa9Tpn8sl/CsT6mptRKqYsv9g27MKEKyzWmhS8Ikvfza6wG YKaafpdWvQhYQkoypWHT/w5BE7CeEbJ1y3oUSlAtBwjrvY4c1kbpKt3TjXfqTz0V G1F0uXb02XGhZK9x6P/gfX5HmVTPOet27YBagt2MP8/1wUVhobD6zcWfVqeUrPMz zFvfJm/k+Rh0s0AHh0GNESkY4gpbLgHfjxzO2WJfaz6wCIz1XZwGywHhA/lkspgm d3w4wUHDbbstCj8v/BycbU3WHrhWmqUrWsSJGCgFmdr23dDJFQeHcN/w5temmx2E nlX0yUq9Wm74x/iUmNf5+nKe/SXiSf7cNtUFvTMErVvqL1hwgT52SHoMFusV1Kkx 6MwrUVhqsrRGlfrLL8qNPDZQb5t7BVf0Tj+uRmIB8czEyfIADPXRhpa0H4+M0Sfd cgJ8cFo4hCSIfn6VMpSl =o9Gc -----END PGP SIGNATURE----- --Apple-Mail=_A61B5B61-D22A-4A4C-9A17-34CDD74809B4--