Hi Clemens, On Jan 30, 2014, at 1:09 PM, Clemens Eisserer wrote: > Hi Vyacheslav, > >> So, as a result, when you are talking about logical block placement >> then it doesn't mean that you are talking about writes in few physical >> erase blocks. Because only mapping table of FTL knows what physical >> erase blocks are changed really. > ntly). > > For powerful FTL/controllers it almost doesn't make a difference > whether you write in-place or in the "almost random" style you > propose. > Those FTLs usually have a fully associative fine-grained > physical-to-logical mapping, so they also can distribute the wear > evenly across the entire NAND. > I suppose that current implementation is not bad. And it is possible to give what you want by simple management of superblock's update timeout. Because and now superblock is updated on mount/umount and with frequency is defined by some timeout. > However there are also FTLs (SD cards, managed NAND, ...) arround > which do only mapping on erase-block level, with limited associativity > - often lacking a random write unit. > So each logical block is mapped to one of n possible physical erase > blocks (for SD cards 4MB erase blocks are quite common) and for each > single write a full erase block has to be erased. And as there are > only n physcial blocks which can be mapped to this logical block, the > card pretty soon starts to develop bad sectors (even worse, these days > often cheap TLC flash is used limited to < 500 erase cycles). > Ok. But I can't see anything bad for my approach. Because primary reserved area will be 8MB. So, if super root (and all other info) is 4KB, for example, then we can do 2048 write operations without any erase operations. It means that if you will save super root for every full segment then you need to fill 16 GB of volume by data. I think that if reserved area will be fully filled with one iteration of whole volume filling then it will good policy for any FTL. As a result, if you will save super root after 10 segments construction then it will be 160 GB volume; to save super root for 100 segments construction -> 1 TB volume. Moreover, it is possible to distribute load between two areas (primary and secondary) and to increase size of reservation. And it gives opportunity to decrease count of segments between super roots saving in reserved areas. > The linaro guys did a survey on this some time ago: > https://wiki.linaro.org/WorkingGroups/KernelArchived/Projects/FlashCardSurvey > Very interesting is the paragraph about "Access modes", there are > still a lot of controllers which don't feature a random write unit. > Thank you for the link. Thanks, Vyacheslav Dubeyko. >> We know about clean (or unclean) umount from the superblock. >> So, you should update superblock for keeping such knowledge. >> Otherwise, you will need to perform linear scan always. >> I don't quite follow your thought. If we will not update superblock then >> how we can save any changes in superblock? > > Only update the superblock at mount/unmount time, and do a linear scan > in the case of an unclean shutdown. > > Thanks, Clemens -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
