Message-ID: <1349788210.1787.7.camel@kjgkr>
Date:	Tue, 09 Oct 2012 22:10:10 +0900
From:	Jaegeuk Kim <jaegeuk.kim@...il.com>
To:	Luk Czerner <lczerner@...hat.com>
Cc:	Jaegeuk Kim <jaegeuk.kim@...sung.com>,
	'Namjae Jeon' <linkinjeon@...il.com>,
	'Vyacheslav Dubeyko' <slava@...eyko.com>,
	'Marco Stornelli' <marco.stornelli@...il.com>,
	'Al Viro' <viro@...iv.linux.org.uk>, tytso@....edu,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	chur.lee@...sung.com, cm224.lee@...sung.com,
	jooyoung.hwang@...sung.com, linux-fsdevel@...r.kernel.org
Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists