On Fri, Oct 16, 2015 at 03:00:50PM -0600, Warner Losh wrote: > >>>> 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. > > I strongly disagree. That's not seek time in the classic sense. All of those > 100us > are the delay from reading the data from the flash. The reason I'm so adamant > is that adjacent pages read have exactly the same cost. In a spinning disk, > adjacent sectors read have a tiny cost compared to moving the head (seeking). > > Then again, I spent almost three years building a PCIe NAND-based flash > drive, so maybe I'm biased by that experience...
For internal view you right. For external view this delay like seek time. For general HDD total_time = seek_time + transfer_time. seek_time independed of block_size. transfer_time depended of block_size and is block_size/transfer_speed. http://tweakers.net/benchdb/testcombo/3817 https://docs.google.com/spreadsheets/d/1BJ-XY0xwc1JvHJxfOGbcW2Be-q5GQbATcMOh9W0d1-U/edit?usp=sharing This is very closed aproximated by 0.11+block_size/461456. As for HDD. Yes, no real seek. But in all models this is like seek time, regardless of real cause. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
