From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jaegeuk Kim Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system Date: Mon, 08 Oct 2012 19:52:03 +0900 Message-ID: <004a01cda542$f398e2c0$dacaa840$%kim@samsung.com> References: <415E76CC-A53D-4643-88AB-3D7D7DC56F98@dubeyko.com> <9DE65D03-D4EA-4B32-9C1D-1516EAE50E23@dubeyko.com> <1349553966.12699.132.camel@kjgkr> <50712AAA.5030807@gmail.com> <002201cda46e$88b84d30$9a28e790$%kim@samsung.com> <004101cda52e$72210e20$56632a60$%kim@samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: 'Vyacheslav Dubeyko' , 'Marco Stornelli' , 'Jaegeuk Kim' , 'Al Viro' , tytso@mit.edu, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, chur.lee@samsung.com, cm224.lee@samsung.com, jooyoung.hwang@samsung.com, linux-fsdevel@vger.kernel.org To: 'Namjae Jeon' Return-path: In-reply-to: Content-language: ko Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > -----Original Message----- > From: Namjae Jeon [mailto:linkinjeon@gmail.com] > Sent: Monday, October 08, 2012 7:00 PM > To: Jaegeuk Kim > Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; tytso@= mit.edu; > gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org; chur.lee@sa= msung.com; cm224.lee@samsung.com; > jooyoung.hwang@samsung.com; linux-fsdevel@vger.kernel.org > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system >=20 > 2012/10/8, Jaegeuk Kim : > >> -----Original Message----- > >> From: Vyacheslav Dubeyko [mailto:slava@dubeyko.com] > >> Sent: Sunday, October 07, 2012 9:09 PM > >> To: Jaegeuk Kim > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; tytso@mit.edu; > >> gregkh@linuxfoundation.org; linux- > >> kernel@vger.kernel.org; chur.lee@samsung.com; cm224.lee@samsung.co= m; > >> jooyoung.hwang@samsung.com; > >> linux-fsdevel@vger.kernel.org > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file sys= tem > >> > >> Hi, > >> > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote: > >> > >> >> -----Original Message----- > >> >> From: Marco Stornelli [mailto:marco.stornelli@gmail.com] > >> >> Sent: Sunday, October 07, 2012 4:10 PM > >> >> To: Jaegeuk Kim > >> >> Cc: Vyacheslav Dubeyko; jaegeuk.kim@samsung.com; Al Viro; > >> >> tytso@mit.edu; gregkh@linuxfoundation.org; > >> >> linux-kernel@vger.kernel.org; chur.lee@samsung.com; > >> >> cm224.lee@samsung.com; > >> jooyoung.hwang@samsung.com; > >> >> linux-fsdevel@vger.kernel.org > >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file = system > >> >> > >> >> Il 06/10/2012 22:06, Jaegeuk Kim ha scritto: > >> >>> 2012-10-06 (=ED=86=A0), 17:54 +0400, Vyacheslav Dubeyko: > >> >>>> Hi Jaegeuk, > >> >>> > >> >>> Hi. > >> >>> We know each other, right? :) > >> >>> > >> >>>> > >> >>>>> From: =EA=B9=80=EC=9E=AC=EA=B7=B9 > >> >>>>> To: viro@zeniv.linux.org.uk, 'Theodore Ts'o' , > >> >> gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, > >> >> chur.lee@samsung.com, > >> cm224.lee@samsung.com, > >> >> jaegeuk.kim@samsung.com, jooyoung.hwang@samsung.com > >> >>>>> Subject: [PATCH 00/16] f2fs: introduce flash-friendly file= system > >> >>>>> Date: Fri, 05 Oct 2012 20:55:07 +0900 > >> >>>>> > >> >>>>> This is a new patch set for the f2fs file system. > >> >>>>> > >> >>>>> What is F2FS? > >> >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >> >>>>> > >> >>>>> NAND flash memory-based storage devices, such as SSD, eMMC, = and SD > >> >>>>> cards, have > >> >>>>> been widely being used for ranging from mobile to server sys= tems. > >> >>>>> Since they are > >> >>>>> known to have different characteristics from the conventiona= l > >> >>>>> rotational disks, > >> >>>>> a file system, an upper layer to the storage device, should = adapt to > >> >>>>> the changes > >> >>>>> from the sketch. > >> >>>>> > >> >>>>> F2FS is a new file system carefully designed for the NAND fl= ash > >> >>>>> memory-based storage > >> >>>>> devices. We chose a log structure file system approach, but = we tried > >> >>>>> to adapt it > >> >>>>> to the new form of storage. Also we remedy some known issues= of the > >> >>>>> very old log > >> >>>>> structured file system, such as snowball effect of wandering= tree > >> >>>>> and high cleaning > >> >>>>> overhead. > >> >>>>> > >> >>>>> Because a NAND-based storage device shows different characte= ristics > >> >>>>> according to > >> >>>>> its internal geometry or flash memory management scheme aka = =46TL, we > >> >>>>> add various > >> >>>>> parameters not only for configuring on-disk layout, but also= for > >> >>>>> selecting allocation > >> >>>>> and cleaning algorithms. > >> >>>>> > >> >>>> > >> >>>> What about F2FS performance? Could you share benchmarking res= ults of > >> >>>> the new file system? > >> >>>> > >> >>>> It is very interesting the case of aged file system. How is G= C's > >> >>>> implementation efficient? Could > >> >> you share benchmarking results for the very aged file system st= ate? > >> >>>> > >> >>> > >> >>> Although I have benchmark results, currently I'd like to see t= he > >> >>> results > >> >>> measured by community as a black-box. As you know, the results= are > >> >>> very > >> >>> dependent on the workloads and parameters, so I think it would= be > >> >>> better > >> >>> to see other results for a while. > >> >>> Thanks, > >> >>> > >> >> > >> >> 1) Actually it's a strange approach. If you have got any result= s you > >> >> should share them with the community explaining how (the worklo= ad, hw > >> >> and so on) your benchmark works and the specific condition. I r= eally > >> >> don't like the approach "I've got the results but I don't say > >> >> anything, > >> >> if you want a number, do it yourself". > >> > > >> > It's definitely right, and I meant *for a while*. > >> > I just wanted to avoid arguing with how to age file system in th= is > >> > time. > >> > Before then, I share the primitive results as follows. > >> > > >> > 1. iozone in Panda board > >> > - ARM A9 > >> > - DRAM : 1GB > >> > - Kernel: Linux 3.3 > >> > - Partition: 12GB (64GB Samsung eMMC) > >> > - Tested on 2GB file > >> > > >> > seq. read, seq. write, rand. read, rand. write > >> > - ext4: 30.753 17.066 5.06 4.15 > >> > - f2fs: 30.71 16.906 5.073 15.204 > >> > > >> > 2. iozone in Galaxy Nexus > >> > - DRAM : 1GB > >> > - Android 4.0.4_r1.2 > >> > - Kernel omap 3.0.8 > >> > - Partition: /data, 12GB > >> > - Tested on 2GB file > >> > > >> > seq. read, seq. write, rand. read, rand. write > >> > - ext4: 29.88 12.83 11.43 0.56 > >> > - f2fs: 29.70 13.34 10.79 12.82 > >> > > >> > >> > >> This is results for non-aged filesystem state. Am I correct? > >> > > > > Yes, right. > > > >> > >> > Due to the company secret, I expect to show other results after > >> > presenting f2fs at korea linux forum. > >> > > >> >> 2) For a new filesystem you should send the patches to linux-fs= devel. > >> > > >> > Yes, that was totally my mistake. > >> > > >> >> 3) It's not clear the pros/cons of your filesystem, can you sha= re with > >> >> us the main differences with the current fs already in mainline= ? Or is > >> >> it a company secret? > >> > > >> > After forum, I can share the slides, and I hope they will be use= ful to > >> > you. > >> > > >> > Instead, let me summarize at a glance compared with other file s= ystems. > >> > Here are several log-structured file systems. > >> > Note that, F2FS operates on top of block device with considerati= on on > >> > the FTL behavior. > >> > So, JFFS2, YAFFS2, and UBIFS are out-of scope, since they are de= signed > >> > for raw NAND flash. > >> > LogFS is initially designed for raw NAND flash, but expanded to = block > >> > device. > >> > But, I don't know whether it is stable or not. > >> > NILFS2 is one of major log-structured file systems, which suppor= ts > >> > multiple snap-shots. > >> > IMO, that feature is quite promising and important to users, but= it may > >> > degrade the performance. > >> > There is a trade-off between functionalities and performance. > >> > F2FS chose high performance without any further fancy functional= ities. > >> > > >> > >> Performance is a good goal. But fault-tolerance is also very impor= tant > >> point. Filesystems are used by > >> users, so, it is very important to guarantee reliability of data k= eeping. > >> Degradation of performance > >> by means of snapshots is arguable point. Snapshots can solve the p= roblem > >> not only some unpredictable > >> environmental issues but also user's erroneous behavior. > >> > > > > Yes, I agree. I concerned the multiple snapshot feature. > > Of course, fault-tolerance is very important, and file system shoul= d support > > it as you know as power-off-recovery. > > f2fs supports the recovery mechanism by adopting checkpoint similar= to > > snapshot. > > But, f2fs does not support multiple snapshots for user convenience. > > I just focused on the performance, and absolutely, the multiple sna= pshot > > feature is also a good alternative approach. > > That may be a trade-off. > > > >> As I understand, it is not possible to have a perfect performance = in all > >> possible workloads. Could you > >> point out what workloads are the best way of F2FS using? > > > > Basically I think the following workloads will be good for F2FS. > > - Many random writes : it's LFS nature > > - Small writes with frequent fsync : f2fs is optimized to reduce th= e fsync > > overhead. > > > >> > >> > Maybe or obviously it is possible to optimize ext4 or btrfs to f= lash > >> > storages. > >> > IMHO, however, they are originally designed for HDDs, so that it= may or > >> > may not suffer from > >> fundamental designs. > >> > I don't know, but why not designing a new file system for flash = storages > >> > as a counterpart? > >> > > >> > >> Yes, it is possible. But F2FS is not flash oriented filesystem as = JFFS2, > >> YAFFS2, UBIFS but block- > >> oriented filesystem. So, F2FS design is restricted by block-layer'= s > >> opportunities in the using of > >> flash storages' peculiarities. Could you point out key points of F= 2FS > >> design that makes this design > >> fundamentally unique? > > > > As you can see the f2fs kernel document patch, I think one of the m= ost > > important features is to align operating units between f2fs and ftl= =2E > > Specifically, f2fs has section and zone, which are cleaning unit an= d basic > > allocation unit respectively. > > Through these configurable units in f2fs, I think f2fs is able to r= educe the > > unnecessary operations done by FTL. > > And, in order to avoid changing IO patterns by the block-layer, f2f= s 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 devic= e > ? I've known that some works have been tried to figure out the units by p= rofiling the storage, AKA reverse engineering. In most cases, the simplest way is to measure the latencies of consecut= ive writes and analyze their patterns. As you mentioned, in practical, users will not want to do this, so mayb= e we need a tool to profile them to optimize f2fs. In the current state, I think profiling is an another issue, and mkfs.f= 2fs had better include this work in the future. But, IMO, from the viewpoint of performance, default configuration is q= uite enough now. ps) f2fs doesn't care about the flash page size, but considers garbage = collection unit. >=20 > Thanks. >=20 > > > >> > >> With the best regards, > >> Vyacheslav Dubeyko. > >> > >> > >> >> > >> >> Marco > >> > > >> > --- > >> > Jaegeuk Kim > >> > Samsung > >> > > >> > -- > >> > To unsubscribe from this list: send the line "unsubscribe linux-= kernel" > >> > in > >> > the body of a message to majordomo@vger.kernel.org > >> > More majordomo info at http://vger.kernel.org/majordomo-info.ht= ml > >> > Please read the FAQ at http://www.tux.org/lkml/ > > > > > > --- > > Jaegeuk Kim > > Samsung > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-fsd= evel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > --- Jaegeuk Kim Samsung