Il 06/10/2012 22:06, Jaegeuk Kim ha scritto:
2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko:
Hi Jaegeuk,
Hi.
We know each other, right? :)
From: 김재극 <jaegeuk....@samsung.com>
To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' <ty...@mit.edu>,
gre...@linuxfoundation.org, linux-kernel@vger.kernel.org, chur....@samsung.com,
cm224....@samsung.com, jaegeuk....@samsung.com, jooyoung.hw...@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?
=============
NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have
been widely being used for ranging from mobile to server systems. Since they are
known to have different characteristics from the conventional 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 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 tree and high
cleaning
overhead.
Because a NAND-based storage device shows different characteristics 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 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 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 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 anything,
if you want a number, do it yourself".
2) For a new filesystem you should send the patches to linux-fsdevel.
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? Or is
it a company secret?
Marco
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
