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 17:25:16 +0900 Message-ID: <004101cda52e$72210e20$56632a60$%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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE 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.com, jooyoung.hwang@samsung.com, linux-fsdevel@vger.kernel.org To: 'Vyacheslav Dubeyko' Return-path: Received: from mailout1.samsung.com ([203.254.224.24]:48871 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753542Ab2JHIZS convert rfc822-to-8bit (ORCPT ); Mon, 8 Oct 2012 04:25:18 -0400 In-reply-to: Content-language: ko Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > -----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; gregk= h@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 >=20 > Hi, >=20 > On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote: >=20 > >> -----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@mi= t.edu; gregkh@linuxfoundation.org; > >> linux-kernel@vger.kernel.org; chur.lee@samsung.com; cm224.lee@sams= ung.com; > jooyoung.hwang@samsung.com; > >> linux-fsdevel@vger.kernel.org > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file sys= tem > >> > >> 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 sy= stem > >>>>> 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 system= s. Since they are > >>>>> known to have different characteristics from the conventional r= otational disks, > >>>>> a file system, an upper layer to the storage device, should ada= pt to the changes > >>>>> from the sketch. > >>>>> > >>>>> F2FS is a new file system carefully designed for the NAND flash= 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 tr= ee and high cleaning > >>>>> overhead. > >>>>> > >>>>> Because a NAND-based storage device shows different characteris= tics according to > >>>>> its internal geometry or flash memory management scheme aka FTL= , we add various > >>>>> parameters not only for configuring on-disk layout, but also fo= r selecting allocation > >>>>> and cleaning algorithms. > >>>>> > >>>> > >>>> What about F2FS performance? Could you share benchmarking result= s of the new file system? > >>>> > >>>> It is very interesting the case of aged file system. How is GC's= implementation efficient? Could > >> you share benchmarking results for the very aged file system state= ? > >>>> > >>> > >>> Although I have benchmark results, currently I'd like to see the = results > >>> measured by community as a black-box. As you know, the results ar= e 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 results y= ou > >> should share them with the community explaining how (the workload,= hw > >> and so on) your benchmark works and the specific condition. I real= ly > >> don't like the approach "I've got the results but I don't say anyt= hing, > >> 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 this = 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 > > >=20 >=20 > This is results for non-aged filesystem state. Am I correct? >=20 Yes, right. >=20 > > Due to the company secret, I expect to show other results after pre= senting f2fs at korea linux forum. > > > >> 2) For a new filesystem you should send the patches to linux-fsdev= el. > > > > Yes, that was totally my mistake. > > > >> 3) It's not clear the pros/cons of your filesystem, can you share = with > >> us the main differences with the current fs already in mainline? O= r is > >> it a company secret? > > > > After forum, I can share the slides, and I hope they will be useful= to you. > > > > Instead, let me summarize at a glance compared with other file syst= ems. > > Here are several log-structured file systems. > > Note that, F2FS operates on top of block device with consideration = on the FTL behavior. > > So, JFFS2, YAFFS2, and UBIFS are out-of scope, since they are desig= ned for raw NAND flash. > > LogFS is initially designed for raw NAND flash, but expanded to blo= ck device. > > But, I don't know whether it is stable or not. > > NILFS2 is one of major log-structured file systems, which supports = 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 functionaliti= es. > > >=20 > Performance is a good goal. But fault-tolerance is also very importan= t point. Filesystems are used by > users, so, it is very important to guarantee reliability of data keep= ing. Degradation of performance > by means of snapshots is arguable point. Snapshots can solve the prob= lem not only some unpredictable > environmental issues but also user's erroneous behavior. >=20 Yes, I agree. I concerned the multiple snapshot feature. Of course, fault-tolerance is very important, and file system should su= pport 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 snapsho= t 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 the fs= ync overhead. >=20 > > Maybe or obviously it is possible to optimize ext4 or btrfs to flas= h storages. > > IMHO, however, they are originally designed for HDDs, so that it ma= y or may not suffer from > fundamental designs. > > I don't know, but why not designing a new file system for flash sto= rages as a counterpart? > > >=20 > Yes, it is possible. But F2FS is not flash oriented filesystem as JFF= S2, YAFFS2, UBIFS but block- > oriented filesystem. So, F2FS design is restricted by block-layer's o= pportunities in the using of > flash storages' peculiarities. Could you point out key points of F2FS= design that makes this design > fundamentally unique? 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 ba= sic allocation unit respectively. Through these configurable units in f2fs, I think f2fs is able to reduc= e the unnecessary operations done by FTL. And, in order to avoid changing IO patterns by the block-layer, f2fs me= rges itself some bios likewise ext4. >=20 > With the best regards, > Vyacheslav Dubeyko. >=20 >=20 > >> > >> Marco > > > > --- > > Jaegeuk Kim > > Samsung > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-ker= nel" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > Please read the FAQ at http://www.tux.org/lkml/ --- Jaegeuk Kim Samsung -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html