2012-10-09 (화), 14:39 +0200, Lukáš Czerner: > On Tue, 9 Oct 2012, Jaegeuk Kim wrote: > > > > > > > > > > > > > > > > > As you can see the f2fs kernel document patch, I think one of > > > > > > > > the most > > > > > > > > important features is to align operating units between f2fs and > > > > > > > > ftl. > > > > > > > > Specifically, f2fs has section and zone, which are cleaning > > > > > > > > unit and basic > > > > > > > > allocation unit respectively. > > > > > > > > Through these configurable units in f2fs, I think f2fs is able > > > > > > > > to reduce the > > > > > > > > unnecessary operations done by FTL. > > > > > > > > And, in order to avoid changing IO patterns by the block-layer, > > > > > > > > f2fs merges > > > > > > > > itself some bios likewise ext4. > > > > > > > Hello. > > > > > > > The internal of eMMC and SSD is the blackbox from user side. > > > > > > > How does the normal user easily set operating units alignment(page > > > > > > > size and physical block size ?) between f2fs and ftl in storage > > > > > > > device > > > > > > > ? > > > > > > > > > > > > I've known that some works have been tried to figure out the units > > > > > > by profiling the storage, AKA > > > > > reverse engineering. > > > > > > In most cases, the simplest way is to measure the latencies of > > > > > > consecutive writes and analyze > > > their > > > > > patterns. > > > > > > As you mentioned, in practical, users will not want to do this, so > > > > > > maybe we need a tool to > > > profile > > > > > them to optimize f2fs. > > > > > > In the current state, I think profiling is an another issue, and > > > > > > mkfs.f2fs had better include > > > this > > > > > work in the future. > > > > > > But, IMO, from the viewpoint of performance, default configuration > > > > > > is quite enough now. > > > > > > > > > > > > ps) f2fs doesn't care about the flash page size, but considers > > > > > > garbage collection unit. > > > > > > > > > > I am sorry but this reply makes me smile. How can you design a fs > > > > > relying on time attack heuristics to figure out what the proper > > > > > layout should be ? Or even endorse such heuristics to be used in > > > > > mkfs ? What we should be focusing on is to push vendors to actually > > > > > give us such information so we can properly propagate that > > > > > throughout the kernel - that's something everyone will benefit from. > > > > > After that the optimization can be done in every file system. > > > > > > > > > > > > > Frankly speaking, I agree that it would be the right direction > > > > eventually. > > > > But, as you know, it's very difficult for all flash vendors to promote > > > > and standardize that. > > > > Because each vendors have different strategies to open their internal > > > > information and also try > > > > to protect their secrets whatever they are. > > > > > > > > IMO, we don't need to wait them now. > > > > Instead, from the start, I suggest f2fs that uses those information to > > > > the file system design. > > > > In addition, I suggest using heuristics right now as best efforts. > > > > Maybe in future, if vendors give something, f2fs would be more feasible. > > > > In the mean time, I strongly hope to validate and stabilize f2fs with > > > > community. > > > > > > Do not get me wrong, I do not think it is worth to wait for vendors > > > to come to their senses, but it is worth constantly reminding that > > > we *need* this kind of information and those heuristics are not > > > feasible in the long run anyway. > > > > > > I believe that this conversation happened several times already, but > > > what about having independent public database of all the internal > > > information about hw from different vendors where users can add > > > information gathered by the time attack heuristic so other does not > > > have to run this again and again. I am not sure if Linaro or someone > > > else have something like that, someone can maybe post a link to that. > > > > > > > As I mentioned, I agree to push vendors to open those information all the > > time. > > And, I absolutely didn't mean that it is worth to wait vendors. > > I meant, until opening those information by vendors, something like > > proposing f2fs or gathering heuristics are also needed simultaneously. > > > > Anyway, it's very interesting to build a database gathering products' > > information. > > May I access the database? > > That's what I found: > > https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey >
It is very good information when users configure f2fs according to their storages. Thank you. -Jaegeuk Kim > -Lukas > > > > > Thanks, > > > > > Eventually we can show this to the vendors to see that their > > > "secrets" are already public anyway and that everyones lives would be > > > easier if they just agree to provide it from the beginning. > > > > > > > > > > > > Promoting time attack heuristics instead of pushing vendors to tell > > > > > us how their hardware should be used is a journey to hell and we've > > > > > been talking about this for a looong time now. And I imagine that > > > > > you especially have quite some persuasion power. > > > > > > > > I know. :) > > > > If there comes a chance, I want to try. > > > > Thanks, > > > > > > That's very good to hear, thank you. > > > > > > -Lukas -- Jaegeuk Kim Samsung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
