Slide 1Slide 2Slide 3Slide 4Slide 5Slide 6Slide 7Slide 8Slide 9Slide 10Slide 11Slide 12Slide 13Slide 14Slide 15Slide 16Slide 17Slide 18Slide 19Slide 20Slide 21Slide 22Slide 23Slide 24Slide 25Slide 26OutlineMotivation and backgroundRead Read “seek” timeGood sequential readWriteWrite log block (buffer)“1” !=”0”? Conclusion and future workMotivationEra for Flash?Nice properties: Fast random access; Shock / Temperature resistance ; Smaller size and weight.Energy saving. Reducing price + increasing volume.We only get BLACK BOX.Industry company may not tell?No systematic performance study literature?Flash Memory OrganizationEach page: 2KB,4KBEach block: 64,128 pagesRead and WriteRead in pages ~50usWrite in pages ~800usAny write needs block erase ~1500us ......Block 0 Block 1 Block n-1Page 0Page m-1Page 3Page 2Page 1......Chip organizationOutlineMotivation and backgroundRead Read Read “seek” time.Read “seek” time.Good sequential read.Good sequential read.WriteWrite buffer size.“1” !=”0”? Conclusion and future workRead Assumptions and basic knowledgeUniform random read time?Good sequential read performance? Experiments SetupFedora Core 7.0,1GHZ CPU, 1G MemoryFlash memory(I) Kingston DataTraveler 1G(II) PNY Attaché 2G(III) Unknown 1GRandom Read-- “seek” timeSequential Read –good!Sequential Read –Scale upRead –what we can do?Technology aware FSBlock group VS Cylinder groupTo Group files. Random read is good but not perfect. To decrement random accesses.OutlineMotivation and backgroundRead Read “seek” timeGood sequential readWriteWriteWrite log block (buffer)Write log block (buffer)““1” !=”0”? 1” !=”0”? ConclusionWriteAssumptions and basic knowledgeBad random write performanceNeeds block erase (1 page--> block erase)Good sequential write performanceLimited block erase times (64 pages--> block erase) Reason : Log (buffer) and MergeWrite -- merge valid valid valid valid valid valid valid validData BlockLog BlockFree Data Block1.Write2.merge 2.merge3.erase3.eraseLog Block PoolRandom Write -- bad!Continuous write – great relief from eraseWrite -- log blockWhat is it?Flash block as write bufferCorrespond to one flash block at one timeWhy is it used?Hard disk : clustering writes; save redundantFlash disk: reduce erase timesInteresting: Log block size and usageLog block -- sizeMotivationTrade off: Large merge time VS frequent mergeSize: 64 pages 128 pagesDetermine size of Log block poolRepeat writing one page into set of continuous flash blocks sequentially. Check the time cost. Block # Time(us) Block # Time(us)1 120161 1 1205002 120231 2 1201093 118823 3 1205751 2735 4 1193162 2691 1 1191523 2708 2 1197431 4555 3 1197082 1805 4 1184523 2942 1 1188272 1207963 1218154 120943Log block pool -- Use StrategyLog block pool use FIFO to reclaim used blocksRepeatedly writing less than 16 pages into one flash block does not trigger data merge.“0” != “1”How about 50%?Write -- what we can do? New file system for flashModified LFS Log block !=write bufferSpecial policy for frequently updated data, e.g inodesAnticipatory schedulingMore flexible. Directly execute any write request in one data block associated with log block.Flip “1” to “0”, “0” to “1” may save time (attributed to Remzi)Conclusion Comprehensive study of the read and write performance of flash memoryDesign a relatively systematic method to study the flash memory as a black boxFind some interesting and potentially useful properties, e.g. “1”!=”0” ; “seek” time Apply similar performance study strategy to SSD and check whether the properties still holdQ&ARandom Read-- “seek” timeRandom Read-- “seek”
View Full Document
Unlocking...