> -----Original Message----- > From: linux-fsdevel-owner@xxxxxxxxxxxxxxx [mailto:linux-fsdevel-owner@xxxxxxxxxxxxxxx] On Behalf Of > Dave Chinner > Sent: Wednesday, October 10, 2012 6:20 AM > To: Jaegeuk Kim > Cc: 'Lukáš Czerner'; 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; > tytso@xxxxxxx; gregkh@xxxxxxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; chur.lee@xxxxxxxxxxx; > cm224.lee@xxxxxxxxxxx; jooyoung.hwang@xxxxxxxxxxx; linux-fsdevel@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system > > [ Folks, can you trim your responses down to just quote the part you > are responding to? Having to repeatedly scroll through 500 lines of > irrelevant text just to find the 5 lines that is being commented on > is exceedingly painful. ] Ok, I'll keep in mind. Thanks. > > On Tue, Oct 09, 2012 at 09:01:18PM +0900, Jaegeuk Kim wrote: > > > From: Lukáš Czerner [mailto:lczerner@xxxxxxxxxx] > > > > > 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. > > And in response, other people are "suggesting" that this is the > wrong approach. Ok, it makes sense. I agree that the Linaro survey has been well proceeded, and no more heuristic is needed. > > > > > 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. > > Linaro already have one, which is another reason why using > heuristics is the wrong approach: > > https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey?action=show&redirect=WorkingGrou > ps%2FKernelConsolidation%2FProjects%2FFlashCardSurvey > > > 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? > > It's public information. > > If you want to support different types of flash, then either add > your timing attack derived information on specific hardware to the > above table, or force vendors to update it themselves if they want > their flash memory supported by this filesystem. Sound good. If I also get something, I'll try. Thank you. > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
