Date: Fri, 16 Oct 2015 13:22:44 -0600 From: Warner Losh <imp@bsdimp.com> To: Slawa Olhovchenkov <slw@zxy.spb.ru> Cc: 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: <3ADA7934-3EE1-449E-A8D1-723B73020C13@bsdimp.com> In-Reply-To: <20151016131940.GE42243@zxy.spb.ru> References: <201510160306.t9G3622O049128@repo.freebsd.org> <20151016131940.GE42243@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] > On Oct 16, 2015, at 7:19 AM, Slawa Olhovchenkov <slw@zxy.spb.ru> wrote: > > On Fri, Oct 16, 2015 at 03:06:02AM +0000, Warner Losh wrote: > >> Author: imp >> Date: Fri Oct 16 03:06:02 2015 >> New Revision: 289405 >> URL: https://svnweb.freebsd.org/changeset/base/289405 >> >> Log: >> Do not relocate extents to make them contiguous if the underlying drive can do >> deletions. Ability to do deletions is a strong indication that this >> optimization will not help performance. It will only generate extra write >> traffic. These devices are typically flash based and have a limited number of >> write cycles. In addition, making the file contiguous in LBA space doesn't >> improve the access times from flash devices because they have no seek time. > > In reality, flash devices have seek time, about 0.1ms. > Many flash devices can do 8 simultaneously "seek" (I think NVMe can do > more). That’s just not true. tREAD for most flash is a few tens of microseconds. The streaming time is at most 10 microseconds. There’s no “seek” time in the classic sense. Once you get the data, you have it. There’s no extra “read time” in the NAND flash parts. And the number of simultaneous reads depends a lot on how the flash vendor organized the flash. Many of today’s designs use 8 or 16 die parts that have 2 to 4 planes on them, giving a parallelism in the 16-64 range. And that’s before we get into innovative strategies that use partial page reads to decrease tREAD time and novel data striping methods. Seek time, as a separate operation, simply doesn’t exist. Furthermore, NAND-based devices are log-structured with garbage collection for both retention and to deal with retired blocks in the underlying NAND. The relationship between LBA ranges and where the data is at any given time on the NAND is almost uncorrelated. So, rearranging data so that it is in LBA contiguous ranges doesn’t help once you’re above the FFS block level. Warner [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWIU6EAAoJEGwc0Sh9sBEAbIYP/RtYW6TeKYHBOuL2JWV3Srud 6z6oXEp/U8dq1fZSrvJuKCxXaZXbFAaDSWabv1qayx+xhWDaJljorQIzlhVuSmOC Mvk5pZMEMHcEnxquZ9QT9rAfYXtUgbpBAhjeQsKwk5USb+5oTL1dzkYZZkS0CwhM /aB8PaKX3iMvRgsr540ZdfXOCpHA1K7ntLr5Eb9ZETZ6eexrhQUE/+wIVrUpr+kt gGPUNRjr375jAiObt6PWzl32OlnfJHTvU+R0N5ZVPWNMBGurLWiNGrT4BCMM4KLj Xc4Kaiv/AkcJjI8q2EdlprUDH7dyHTiXndYHgI7VEVzv3JHa7QIvMZLk5UVUCYCr Xs4BX0SdZ2xaNYi1JUPkoRxv6bsrpKMRtfH6WuJAKJwgGEfJhMkocFXtYhl/JUbO Oli7DXKEYd3KwRA9Acn/4/RWk7unL+j4rWQMiWtzTA5KHxh+9kTP0W6Y6pFsjKFv zl1sZLw5ACUipRJuCJLBdUn8IdrMR1h3AOJqmdx5VMPIaYTGF8nLqhtuykyTutTA Ta8z+g3DIxc7NO7gI6jJ//L7L2VsUMjvwLG8L+P3HvFVslhbPn9+XK3gixEWYiB2 aq/SW3dFWqvItmo0hD394ZRN/+sf/jpk026MrrC/e9+t6no+VvBxu1BZQIL5nnUh UMJYjYECkz5UT/CIzgq0 =bUtC -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ADA7934-3EE1-449E-A8D1-723B73020C13>