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: Sun, 07 Oct 2012 18:31:30 +0900 Message-ID: <002201cda46e$88b84d30$9a28e790$%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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: 'Vyacheslav Dubeyko' , '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: 'Marco Stornelli' , 'Jaegeuk Kim' Return-path: Received: from mailout4.samsung.com ([203.254.224.34]:45077 "EHLO mailout4.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750887Ab2JGJbd convert rfc822-to-8bit (ORCPT ); Sun, 7 Oct 2012 05:31:33 -0400 In-reply-to: <50712AAA.5030807@gmail.com> Content-language: ko Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > -----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.e= du; gregkh@linuxfoundation.org; > linux-kernel@vger.kernel.org; chur.lee@samsung.com; cm224.lee@samsung= =2Ecom; jooyoung.hwang@samsung.com; > linux-fsdevel@vger.kernel.org > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system >=20 > 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@sa= msung.com, cm224.lee@samsung.com, > jaegeuk.kim@samsung.com, jooyoung.hwang@samsung.com > >>> Subject: [PATCH 00/16] f2fs: introduce flash-friendly file syst= em > >>> 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 S= D cards, have > >>> been widely being used for ranging from mobile to server systems.= Since they are > >>> known to have different characteristics from the conventional rot= ational 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 flash m= emory-based storage > >>> devices. We chose a log structure file system approach, but we tr= ied to adapt it > >>> to the new form of storage. Also we remedy some known issues of t= he 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 characteristi= cs 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 for = selecting allocation > >>> and cleaning algorithms. > >>> > >> > >> What about F2FS performance? Could you share benchmarking results = of the new file system? > >> > >> It is very interesting the case of aged file system. How is GC's i= mplementation 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 re= sults > > 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 b= etter > > to see other results for a while. > > Thanks, > > >=20 > 1) Actually it's a strange approach. If you have got any results you > should share them with the community explaining how (the workload, hw > and so on) your benchmark works and the specific condition. I really > don't like the approach "I've got the results but I don't say anythin= g, > 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= =2E 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 Due to the company secret, I expect to show other results after present= ing f2fs at korea linux forum. > 2) For a new filesystem you should send the patches to linux-fsdevel. Yes, that was totally my mistake. > 3) It's not clear the pros/cons of your filesystem, can you share wit= h > us the main differences with the current fs already in mainline? Or i= s > 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 systems. Here are several log-structured file systems. Note that, F2FS operates on top of block device with consideration on t= he FTL behavior. So, JFFS2, YAFFS2, and UBIFS are out-of scope, since they are designed = for raw NAND flash. LogFS is initially designed for raw NAND flash, but expanded to block d= evice. But, I don't know whether it is stable or not. NILFS2 is one of major log-structured file systems, which supports mult= iple 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. =462FS chose high performance without any further fancy functionalities= =2E Maybe or obviously it is possible to optimize ext4 or btrfs to flash st= orages. 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 storage= s as a counterpart? >=20 > Marco --- 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