Date: Fri, 16 Oct 2015 13:24:22 -0600 From: Warner Losh <imp@bsdimp.com> To: Pedro Giffuni <pfg@freebsd.org> Cc: Bruce Evans <brde@optusnet.com.au>, Hans Petter Selasky <hp@selasky.org>, Warner Losh <imp@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r289405 - head/sys/ufs/ffs Message-ID: <C06E609D-6D4F-4B1B-B845-D6366D43123B@bsdimp.com> In-Reply-To: <562103B6.2090406@FreeBSD.org> References: <201510160306.t9G3622O049128@repo.freebsd.org> <20151016151349.W1280@besplex.bde.org> <5620B15C.8090104@selasky.org> <20151016194242.N2138@besplex.bde.org> <562103B6.2090406@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <pfg@freebsd.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C06E609D-6D4F-4B1B-B845-D6366D43123B>