svn commit: r289405 - head/sys/ufs/ffs

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 01:22:44PM -0600, Warner Losh wrote:

> 
> > On Oct 16, 2015, at 7:19 AM, Slawa Olhovchenkov <slw at 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.

Stream of random reads 512-4096 bytes from most flash SATA drives in one
thread give about 10K IOPS. This is only 40Mbit/s from 6*0.8 Gbit/s
SATA bandwidth. You may decompose 0.1ms to different, real delay (bank
select, command process and etc.) or give 0.1ms seek time for all
practical purpose.