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
[-- Attachment #1 --] > On Oct 16, 2015, at 8:03 AM, Pedro Giffuni <pfg@freebsd.org> wrote: > > > > On 10/16/15 03:53, Bruce Evans wrote: >> On Fri, 16 Oct 2015, Hans Petter Selasky wrote: >> >>> 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. >>> >>> 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. >> >> 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. >> > > I agree with Bruce: reallocation (which our ext2fs also does) happens > in memory, before it hits the disk. > > 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. > > 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’t 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 [-- Attachment #2 --] -----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-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C06E609D-6D4F-4B1B-B845-D6366D43123B>