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
--Apple-Mail=_7FB987D8-D45D-47AC-8C10-CDCA9B1DCE46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Oct 16, 2015, at 7:19 AM, Slawa Olhovchenkov <slw@zxy.spb.ru> = wrote: >=20 > On Fri, Oct 16, 2015 at 03:06:02AM +0000, Warner Losh wrote: >=20 >> Author: imp >> Date: Fri Oct 16 03:06:02 2015 >> New Revision: 289405 >> URL: https://svnweb.freebsd.org/changeset/base/289405 >>=20 >> 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. >=20 > 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=E2=80=99s just not true. tREAD for most flash is a few tens of = microseconds. The streaming time is at most 10 microseconds. There=E2=80=99s no =E2=80=9Csee= k=E2=80=9D time in the classic sense. Once you get the data, you have it. There=E2=80=99s no extra = =E2=80=9Cread time=E2=80=9D 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=E2=80=99s 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=E2=80=99s 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=E2=80=99t 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=E2=80=99= t help once you=E2=80=99re above the FFS block level. Warner --Apple-Mail=_7FB987D8-D45D-47AC-8C10-CDCA9B1DCE46 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 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----- --Apple-Mail=_7FB987D8-D45D-47AC-8C10-CDCA9B1DCE46--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3ADA7934-3EE1-449E-A8D1-723B73020C13>