subject:"RE\: \[PATCH 00\/16\] f2fs\: introduce flash\-friendly file system"

2012/10/11, Changman Lee :
> 2012년 10월 11일 목요일에 Namjae Jeon님이 작성:
>> 2012/10/10 Jaegeuk Kim :
>>

 I mean that every volume is placed inside any partition (MTD or GPT).
> Every partition begins from any
 physical sector. So, as I can understand, f2fs volume can begin from
> physical sector that is laid
 inside physical erase block. Thereby, in such case of formating the
> f2fs's operation units will be
 unaligned in relation of physical erase blocks, from my point of view.
> Maybe, I misunderstand
 something but it can lead to additional FTL operations and performance
> degradation, from my point of
 view.
>>>
>>> I think mkfs already calculates the offset to align that.
>> I think this answer is not what he want.
>> If you don't use partition table such as dos partition table or gpt, I
>> think that it is possible to align using mkfs.
>> But If we should consider partition table space in storage, I don't
>> understand how it  could be align using mkfs.
>>
>> Thanks.
>
> We can know the physical starting sector address of any partitions from
> hdio geometry information got by ioctl.
If so, first block and end block of partition are useless ?

Thanks.
>
>>> Thanks,
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel"
> in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> --
>> 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/
>>
>
--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012/10/13, Jaegeuk Kim :
> 2012-10-13 (토), 13:26 +0900, Namjae Jeon:
>> Is there high possibility that the storage device can be rapidly
>> worn-out by cleaning process ? e.g. severe fragmentation situation by
>> creating and removing small files.
>>
>
> Yes, the cleaning process in F2FS induces additional writes so that
> flash storage can be worn out quickly.
> However, how about in traditonal file systems?
> As all of us know that, FTL has an wear-leveling issue too due to the
> garbage collection overhead that is fundamentally similar to the
> cleaning overhead in LFS or F2FS.
>
> So, what's the difference between them?
> IMHO, the major factor to reduce the cleaning or garbage collection
> overhead is how to efficiently separate hot and cold data.
> So, which is a better layer between FTL and file system to achieve that?
> I think the answer is the file system, since the file system has much
> more information on such a hotness of all the data, but FTL doesn't know
> or is hard to figure out that kind of information.
>
> Therefore, I think the LFS approach is more beneficial to span the life
> time of the storage rather than traditional one.
> And, in order to do this perfectly, one thing is a criteria, the
> alignment between FTL and F2FS.

As you know, Normally users don't use one big partition on eMMC.
It means they divide several small parititions.
And F2fs will work on each small partition.
And eMMC's FTL is globally working on whole device.
I can not imagine how to work synchronously beween cleaning process of
f2fs and FTL of eMMC.

And Would you share ppt or document of f2fs if Korea Linux Forum is finished ?

Thanks.
>
>> And you told us only advantages of f2fs. Would you tell us the
>> disadvantages ?
>
> I think there is a scenario like this.
> 1) One big file is created and written data sequentially.
> 2) Many random writes are done across the whole file range.
> 3) User discards cached data by doing "drop_caches" or "reboot".
>
> At this point, I worry about the sequential read performance due to the
> fragmentation.
> I don't know how frequently this use-case happens, but it is one of cons
> in the LFS approach.
> Nevertheless, I'm thinking that the performance could be enhanced by
> cooperating with a readahead mechanism in VFS.
>
> Thanks,
>
>>
>> Thanks.
>
> --
> Jaegeuk Kim
> Samsung
>
>
--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012/10/13, Jaegeuk Kim jaegeuk@gmail.com:
 2012-10-13 (토), 13:26 +0900, Namjae Jeon:
 Is there high possibility that the storage device can be rapidly
 worn-out by cleaning process ? e.g. severe fragmentation situation by
 creating and removing small files.


 Yes, the cleaning process in F2FS induces additional writes so that
 flash storage can be worn out quickly.
 However, how about in traditonal file systems?
 As all of us know that, FTL has an wear-leveling issue too due to the
 garbage collection overhead that is fundamentally similar to the
 cleaning overhead in LFS or F2FS.

 So, what's the difference between them?
 IMHO, the major factor to reduce the cleaning or garbage collection
 overhead is how to efficiently separate hot and cold data.
 So, which is a better layer between FTL and file system to achieve that?
 I think the answer is the file system, since the file system has much
 more information on such a hotness of all the data, but FTL doesn't know
 or is hard to figure out that kind of information.

 Therefore, I think the LFS approach is more beneficial to span the life
 time of the storage rather than traditional one.
 And, in order to do this perfectly, one thing is a criteria, the
 alignment between FTL and F2FS.

As you know, Normally users don't use one big partition on eMMC.
It means they divide several small parititions.
And F2fs will work on each small partition.
And eMMC's FTL is globally working on whole device.
I can not imagine how to work synchronously beween cleaning process of
f2fs and FTL of eMMC.

And Would you share ppt or document of f2fs if Korea Linux Forum is finished ?

Thanks.

 And you told us only advantages of f2fs. Would you tell us the
 disadvantages ?

 I think there is a scenario like this.
 1) One big file is created and written data sequentially.
 2) Many random writes are done across the whole file range.
 3) User discards cached data by doing drop_caches or reboot.

 At this point, I worry about the sequential read performance due to the
 fragmentation.
 I don't know how frequently this use-case happens, but it is one of cons
 in the LFS approach.
 Nevertheless, I'm thinking that the performance could be enhanced by
 cooperating with a readahead mechanism in VFS.

 Thanks,


 Thanks.

 --
 Jaegeuk Kim
 Samsung


--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012/10/11, Changman Lee cm224@gmail.com:
 2012년 10월 11일 목요일에 Namjae Jeonlinkinj...@gmail.com님이 작성:
 2012/10/10 Jaegeuk Kim jaegeuk@samsung.com:


 I mean that every volume is placed inside any partition (MTD or GPT).
 Every partition begins from any
 physical sector. So, as I can understand, f2fs volume can begin from
 physical sector that is laid
 inside physical erase block. Thereby, in such case of formating the
 f2fs's operation units will be
 unaligned in relation of physical erase blocks, from my point of view.
 Maybe, I misunderstand
 something but it can lead to additional FTL operations and performance
 degradation, from my point of
 view.

 I think mkfs already calculates the offset to align that.
 I think this answer is not what he want.
 If you don't use partition table such as dos partition table or gpt, I
 think that it is possible to align using mkfs.
 But If we should consider partition table space in storage, I don't
 understand how it  could be align using mkfs.

 Thanks.

 We can know the physical starting sector address of any partitions from
 hdio geometry information got by ioctl.
If so, first block and end block of partition are useless ?

Thanks.

 Thanks,

 --
 To unsubscribe from this list: send the line unsubscribe linux-fsdevel
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
 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/


--
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/

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-17 Thread Changman Lee

 -Original Message-
 From: Namjae Jeon [mailto:linkinj...@gmail.com]
 Sent: Wednesday, October 17, 2012 8:14 PM
 To: Changman Lee
 Cc: Jaegeuk Kim; Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
 ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
 chur@samsung.com; cm224@samsung.com; jooyoung.hw...@samsung.com;
 linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 2012/10/11, Changman Lee cm224@gmail.com:
  2012년 10월 11일 목요일에 Namjae Jeonlinkinj...@gmail.com님이 작성:
  2012/10/10 Jaegeuk Kim jaegeuk@samsung.com:

  I mean that every volume is placed inside any partition (MTD or GPT).
  Every partition begins from any
  physical sector. So, as I can understand, f2fs volume can begin from
  physical sector that is laid
  inside physical erase block. Thereby, in such case of formating the
  f2fs's operation units will be
  unaligned in relation of physical erase blocks, from my point of view.
  Maybe, I misunderstand
  something but it can lead to additional FTL operations and performance
  degradation, from my point of
  view.

  I think mkfs already calculates the offset to align that.
  I think this answer is not what he want.
  If you don't use partition table such as dos partition table or gpt, I
  think that it is possible to align using mkfs.
  But If we should consider partition table space in storage, I don't
  understand how it  could be align using mkfs.

  Thanks.

  We can know the physical starting sector address of any partitions from
  hdio geometry information got by ioctl.
 If so, first block and end block of partition are useless ?

 Thanks.

For example.
If we try to align a start point of F2FS in 2MB but start sector of any 
partition is not aligned in 2MB,
and of course F2FS will have some unused blocks. Instead, F2FS could reduce gc 
cost of ftl.
I don't know my answer is what you want.

  Thanks,

  --
  To unsubscribe from this list: send the line unsubscribe linux-fsdevel
  in
  the body of a message to majord...@vger.kernel.org
  More majordomo info at  http://vger.kernel.org/majordomo-info.html
  --
  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/

--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-13 Thread Jaegeuk Kim

2012-10-13 (토), 13:26 +0900, Namjae Jeon:
> Is there high possibility that the storage device can be rapidly
> worn-out by cleaning process ? e.g. severe fragmentation situation by
> creating and removing small files.
> 

Yes, the cleaning process in F2FS induces additional writes so that
flash storage can be worn out quickly.
However, how about in traditonal file systems?
As all of us know that, FTL has an wear-leveling issue too due to the
garbage collection overhead that is fundamentally similar to the
cleaning overhead in LFS or F2FS.

So, what's the difference between them?
IMHO, the major factor to reduce the cleaning or garbage collection
overhead is how to efficiently separate hot and cold data.
So, which is a better layer between FTL and file system to achieve that?
I think the answer is the file system, since the file system has much
more information on such a hotness of all the data, but FTL doesn't know
or is hard to figure out that kind of information.

Therefore, I think the LFS approach is more beneficial to span the life
time of the storage rather than traditional one.
And, in order to do this perfectly, one thing is a criteria, the
alignment between FTL and F2FS.

> And you told us only advantages of f2fs. Would you tell us the disadvantages ?

I think there is a scenario like this.
1) One big file is created and written data sequentially.
2) Many random writes are done across the whole file range.
3) User discards cached data by doing "drop_caches" or "reboot".

At this point, I worry about the sequential read performance due to the
fragmentation.
I don't know how frequently this use-case happens, but it is one of cons
in the LFS approach.
Nevertheless, I'm thinking that the performance could be enhanced by
cooperating with a readahead mechanism in VFS.

Thanks,

> 
> Thanks.

-- 
Jaegeuk Kim
Samsung

--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-13 Thread Jaegeuk Kim

2012-10-13 (토), 13:26 +0900, Namjae Jeon:
 Is there high possibility that the storage device can be rapidly
 worn-out by cleaning process ? e.g. severe fragmentation situation by
 creating and removing small files.
 

Yes, the cleaning process in F2FS induces additional writes so that
flash storage can be worn out quickly.
However, how about in traditonal file systems?
As all of us know that, FTL has an wear-leveling issue too due to the
garbage collection overhead that is fundamentally similar to the
cleaning overhead in LFS or F2FS.

So, what's the difference between them?
IMHO, the major factor to reduce the cleaning or garbage collection
overhead is how to efficiently separate hot and cold data.
So, which is a better layer between FTL and file system to achieve that?
I think the answer is the file system, since the file system has much
more information on such a hotness of all the data, but FTL doesn't know
or is hard to figure out that kind of information.

Therefore, I think the LFS approach is more beneficial to span the life
time of the storage rather than traditional one.
And, in order to do this perfectly, one thing is a criteria, the
alignment between FTL and F2FS.

 And you told us only advantages of f2fs. Would you tell us the disadvantages ?

I think there is a scenario like this.
1) One big file is created and written data sequentially.
2) Many random writes are done across the whole file range.
3) User discards cached data by doing drop_caches or reboot.

At this point, I worry about the sequential read performance due to the
fragmentation.
I don't know how frequently this use-case happens, but it is one of cons
in the LFS approach.
Nevertheless, I'm thinking that the performance could be enhanced by
cooperating with a readahead mechanism in VFS.

Thanks,

 
 Thanks.

-- 
Jaegeuk Kim
Samsung

--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Wednesday 10 October 2012 11:36:14 David Woodhouse wrote:
> The whole thing is silly. What we actually want on an embedded system is
> to ditch the FTL altogether and have direct access to the NAND. Then we
> can know our file system is behaving optimally. And we don't need
> hacks like TRIM to try to make things a little less broken.

I think it's safe to say that the times for raw flash in consumer devices
are over, whether we like it or not. Even if we could go back to MTD
for internal storage, we'd still need something better than what we
have for removable flash storage such as USB and SD.

(and I know that xD cards are basically raw flash, but have you tried
to buy one recently?)

Arnd
--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Wednesday 10 October 2012 00:53:51 Theodore Ts'o wrote:
> On Tue, Oct 09, 2012 at 01:01:24PM +0200, Lukáš Czerner wrote:
> > 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.
> 
> A number of us has been telling flash vendors exactly this.  The
> technical people do seem to understand.  It's management who seem to
> be primarily clueless, even though this information can be extracted
> by employing timing attacks on the media.  I've pointed this out
> before, and the technical people agree that trying to keep this
> information as a "trade secret" is pointless, stupid, and
> counterproductive.  Trying to get the pointy-haired bosses to
> understand may take quite a while.

For eMMC, I think we should start out defaulting to the characteristics
that are reported by the device, because they are usually correct
and those vendors for which that is not true can hopefully
come to their senses when they see how f2fs performs by default.

For USB media, the protocol does not allow you to specify the
erase block size, so we have to guess.

For SD cards, there is a field in the card's registers, but I've
never seen any value in there other than 4 MB, and in most cases
where that is not true, the standard does not allow encoding
the correct amount: it only allows power-of-two numbers up to
4 MB, and typical numbers these days are 3 MB, 6 MB or 8 MB.

Arnd
--
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/

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-12 Thread Jaegeuk Kim

2012-10-12 (금), 16:30 +0400, Vyacheslav Dubeyko:
> On Wed, 2012-10-10 at 18:43 +0900, Jaegeuk Kim wrote:
> > [snip]
> > > > How about the following scenario?
> > > > 1. data "a" is newly written.
> > > > 2. checkpoint "A" is done.
> > > > 3. data "a" is truncated.
> > > > 4. checkpoint "B" is done.
> > > >
> > > > If fs supports multiple snapshots like "A" and "B" to users, it cannot 
> > > > reuse the space allocated by
> > > > data "a" after checkpoint "B" even though data "a" is safely truncated 
> > > > by checkpoint "B".
> > > > This is because fs should keep data "a" to prepare a roll-back to "A".
> > > > So, even though user sees some free space, LFS may suffer from cleaning 
> > > > due to the exhausted free
> > > space.
> > > > If users want to avoid this, they have to remove snapshots by 
> > > > themselves. Or, maybe automatically?
> > > >
> > > 
> > > I feel that here it exists some misunderstanding in checkpoint/snapshot 
> > > terminology (especially, for
> > > the NILFS2 case). It is possible that NILFS2 volume can contain only 
> > > checkpoints (if user doesn't
> > > created any snapshot). You are right, snapshot cannot be deleted because, 
> > > in other word, user marked
> > > this file system state as important point. But checkpoints can be 
> > > reclaimed easily. I can't see any
> > > problem to reclaim free space from checkpoints in above-mentioned 
> > > scenario in the case of NILFS2. But
> > 
> > I meant that snapshot does checkpoint.
> > And, the problem is related to real file system utilization managed by 
> > NILFS2.
> >  [fs utilization to users]   [fs utilization managed by 
> > NILFS2]
> > X - 1   X - 1
> > 1. new data "a"XX
> > 2. snapshot "A"XX
> > 3. truncate "a"X - 1   X
> > 4. snapshot "B"X - 1   X
> > 
> > After this, user can see X-1, but the performance will be affected by X.
> > Until the snapshot "A" is removed, user will experience the performance 
> > determined by X.
> > Do I misunderstand?
> > 
> 
> Ok. Maybe I have some misunderstanding but checkpoint and snapshot are 
> different things for me (especially, in the case of NILFS2). :-)
> 
> The most important is that f2fs has more efficient scheme of working with 
> checkpoints, from your point of view. If you are right then it is very good. 
> And I need to be more familiar with f2fs code.
> 

Ok, thanks.

> [snip]
> > > As I know, NILFS2 has Garbage Collector that removes checkpoints 
> > > automatically in background. But it
> > > is possible also to force removing as checkpoints as snapshots by hands 
> > > with special utility using. As
> > 
> > If users may not want to remove the snapshots automatically, should they 
> > configure not to do this too?
> > 
> 
> As I know, NILFS2 doesn't delete snapshots automatically but checkpoints - 
> yes. Moreover, it exists nilfs_cleanerd.conf configuration file that makes 
> possible to manage by NILFS cleanerd daemon's behavior (min/max number of 
> clean segments, selection policy, check/clean intervals and so on).
> 

Ok.

> [snip]
> > > > IMHO, user does not need to know how many snapshots there exist and 
> > > > track the fs utilization all the
> > > time.
> > > > (off list: I don't know why cleaning process should be tuned by users.)
> > > >
> > > 
> > > What do you plan to do in the case of users' complains about issues with 
> > > free space reclaiming? If
> > > user doesn't know about checkpoints and haven't any tools for accessing 
> > > to checkpoints then how is it
> > > possible to investigate issues with free space reclaiming on an user side?
> > 
> > Could you explain why reclaiming free space is an issue?
> > IMHO, that issue is caused by adopting multiple snapshots.
> > 
> 
> I didn't mean that reclaiming free space is an issue. I hope that f2fs
> is stable but unfortunately it is not possible for any software to be
> completely without bugs. So, anyway, f2fs users can have some issues
> during using. One of the possible issue can be unexpected situation
> with not reclaiming of free space. So, my question was about
> possibility to investigate such bug on the user's side. From my point
> of view, NILFS2 has very good utilities for such investigation.

You mean fsck?
Of course, we've implemented fsck tool also.
But, why I didn't open it is that code is a mess.
Another reason is that current fsck tool only checks
the consistency of f2fs.
Now we're still working on it to open.

> 
> [snip]
> > > > In our experiments *also* on android phones, we've seen many random 
> > > > patterns with frequent fsync
> > > calls.
> > > > We found that the main problem is database, and I think f2fs is 
> > > > beneficial to this.
> > > 
> > > I think that database is not main use-case on Android phones. The 
> > > dominating use-case can be operation
> >

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-12 Thread Vyacheslav Dubeyko

On Wed, 2012-10-10 at 18:43 +0900, Jaegeuk Kim wrote:
> [snip]
> > > How about the following scenario?
> > > 1. data "a" is newly written.
> > > 2. checkpoint "A" is done.
> > > 3. data "a" is truncated.
> > > 4. checkpoint "B" is done.
> > >
> > > If fs supports multiple snapshots like "A" and "B" to users, it cannot 
> > > reuse the space allocated by
> > > data "a" after checkpoint "B" even though data "a" is safely truncated by 
> > > checkpoint "B".
> > > This is because fs should keep data "a" to prepare a roll-back to "A".
> > > So, even though user sees some free space, LFS may suffer from cleaning 
> > > due to the exhausted free
> > space.
> > > If users want to avoid this, they have to remove snapshots by themselves. 
> > > Or, maybe automatically?
> > >
> > 
> > I feel that here it exists some misunderstanding in checkpoint/snapshot 
> > terminology (especially, for
> > the NILFS2 case). It is possible that NILFS2 volume can contain only 
> > checkpoints (if user doesn't
> > created any snapshot). You are right, snapshot cannot be deleted because, 
> > in other word, user marked
> > this file system state as important point. But checkpoints can be reclaimed 
> > easily. I can't see any
> > problem to reclaim free space from checkpoints in above-mentioned scenario 
> > in the case of NILFS2. But
> 
> I meant that snapshot does checkpoint.
> And, the problem is related to real file system utilization managed by NILFS2.
>  [fs utilization to users]   [fs utilization managed by 
> NILFS2]
> X - 1   X - 1
> 1. new data "a"XX
> 2. snapshot "A"XX
> 3. truncate "a"X - 1   X
> 4. snapshot "B"X - 1   X
> 
> After this, user can see X-1, but the performance will be affected by X.
> Until the snapshot "A" is removed, user will experience the performance 
> determined by X.
> Do I misunderstand?
> 

Ok. Maybe I have some misunderstanding but checkpoint and snapshot are 
different things for me (especially, in the case of NILFS2). :-)

The most important is that f2fs has more efficient scheme of working with 
checkpoints, from your point of view. If you are right then it is very good. 
And I need to be more familiar with f2fs code.

[snip]
> > As I know, NILFS2 has Garbage Collector that removes checkpoints 
> > automatically in background. But it
> > is possible also to force removing as checkpoints as snapshots by hands 
> > with special utility using. As
> 
> If users may not want to remove the snapshots automatically, should they 
> configure not to do this too?
> 

As I know, NILFS2 doesn't delete snapshots automatically but checkpoints - yes. 
Moreover, it exists nilfs_cleanerd.conf configuration file that makes possible 
to manage by NILFS cleanerd daemon's behavior (min/max number of clean 
segments, selection policy, check/clean intervals and so on).

[snip]
> > > IMHO, user does not need to know how many snapshots there exist and track 
> > > the fs utilization all the
> > time.
> > > (off list: I don't know why cleaning process should be tuned by users.)
> > >
> > 
> > What do you plan to do in the case of users' complains about issues with 
> > free space reclaiming? If
> > user doesn't know about checkpoints and haven't any tools for accessing to 
> > checkpoints then how is it
> > possible to investigate issues with free space reclaiming on an user side?
> 
> Could you explain why reclaiming free space is an issue?
> IMHO, that issue is caused by adopting multiple snapshots.
> 

I didn't mean that reclaiming free space is an issue. I hope that f2fs is 
stable but unfortunately it is not possible for any software to be completely 
without bugs. So, anyway, f2fs users can have some issues during using. One of 
the possible issue can be unexpected situation with not reclaiming of free 
space. So, my question was about possibility to investigate such bug on the 
user's side. From my point of view, NILFS2 has very good utilities for such 
investigation.

[snip]
> > > In our experiments *also* on android phones, we've seen many random 
> > > patterns with frequent fsync
> > calls.
> > > We found that the main problem is database, and I think f2fs is 
> > > beneficial to this.
> > 
> > I think that database is not main use-case on Android phones. The 
> > dominating use-case can be operation
> > by multimedia information and operations with small files, from my point of 
> > view.
> > 
> > So, it is possible to extract such key points from the shared paper: (1) 
> > file has complex structure;
> > (2) sequential access is not sequential; (3) auxiliary files dominate; (4) 
> > multiple threads perform
> > I/O.
> > 
> > I am afraid that random modification of different part of files and I/O 
> > operations from multiple
> > threads can lead to significant fragmentation as file fragments as

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-12 Thread Vyacheslav Dubeyko

On Wed, 2012-10-10 at 18:43 +0900, Jaegeuk Kim wrote:
 [snip]
   How about the following scenario?
   1. data a is newly written.
   2. checkpoint A is done.
   3. data a is truncated.
   4. checkpoint B is done.
  
   If fs supports multiple snapshots like A and B to users, it cannot 
   reuse the space allocated by
   data a after checkpoint B even though data a is safely truncated by 
   checkpoint B.
   This is because fs should keep data a to prepare a roll-back to A.
   So, even though user sees some free space, LFS may suffer from cleaning 
   due to the exhausted free
  space.
   If users want to avoid this, they have to remove snapshots by themselves. 
   Or, maybe automatically?
  
  
  I feel that here it exists some misunderstanding in checkpoint/snapshot 
  terminology (especially, for
  the NILFS2 case). It is possible that NILFS2 volume can contain only 
  checkpoints (if user doesn't
  created any snapshot). You are right, snapshot cannot be deleted because, 
  in other word, user marked
  this file system state as important point. But checkpoints can be reclaimed 
  easily. I can't see any
  problem to reclaim free space from checkpoints in above-mentioned scenario 
  in the case of NILFS2. But
 
 I meant that snapshot does checkpoint.
 And, the problem is related to real file system utilization managed by NILFS2.
  [fs utilization to users]   [fs utilization managed by 
 NILFS2]
 X - 1   X - 1
 1. new data aXX
 2. snapshot AXX
 3. truncate aX - 1   X
 4. snapshot BX - 1   X
 
 After this, user can see X-1, but the performance will be affected by X.
 Until the snapshot A is removed, user will experience the performance 
 determined by X.
 Do I misunderstand?
 

Ok. Maybe I have some misunderstanding but checkpoint and snapshot are 
different things for me (especially, in the case of NILFS2). :-)

The most important is that f2fs has more efficient scheme of working with 
checkpoints, from your point of view. If you are right then it is very good. 
And I need to be more familiar with f2fs code.

[snip]
  As I know, NILFS2 has Garbage Collector that removes checkpoints 
  automatically in background. But it
  is possible also to force removing as checkpoints as snapshots by hands 
  with special utility using. As
 
 If users may not want to remove the snapshots automatically, should they 
 configure not to do this too?
 

As I know, NILFS2 doesn't delete snapshots automatically but checkpoints - yes. 
Moreover, it exists nilfs_cleanerd.conf configuration file that makes possible 
to manage by NILFS cleanerd daemon's behavior (min/max number of clean 
segments, selection policy, check/clean intervals and so on).

[snip]
   IMHO, user does not need to know how many snapshots there exist and track 
   the fs utilization all the
  time.
   (off list: I don't know why cleaning process should be tuned by users.)
  
  
  What do you plan to do in the case of users' complains about issues with 
  free space reclaiming? If
  user doesn't know about checkpoints and haven't any tools for accessing to 
  checkpoints then how is it
  possible to investigate issues with free space reclaiming on an user side?
 
 Could you explain why reclaiming free space is an issue?
 IMHO, that issue is caused by adopting multiple snapshots.
 

I didn't mean that reclaiming free space is an issue. I hope that f2fs is 
stable but unfortunately it is not possible for any software to be completely 
without bugs. So, anyway, f2fs users can have some issues during using. One of 
the possible issue can be unexpected situation with not reclaiming of free 
space. So, my question was about possibility to investigate such bug on the 
user's side. From my point of view, NILFS2 has very good utilities for such 
investigation.

[snip]
   In our experiments *also* on android phones, we've seen many random 
   patterns with frequent fsync
  calls.
   We found that the main problem is database, and I think f2fs is 
   beneficial to this.
  
  I think that database is not main use-case on Android phones. The 
  dominating use-case can be operation
  by multimedia information and operations with small files, from my point of 
  view.
  
  So, it is possible to extract such key points from the shared paper: (1) 
  file has complex structure;
  (2) sequential access is not sequential; (3) auxiliary files dominate; (4) 
  multiple threads perform
  I/O.
  
  I am afraid that random modification of different part of files and I/O 
  operations from multiple
  threads can lead to significant fragmentation as file fragments as 
  directory meta-information because
  of garbage collection.
 
 Could you explain in more detail?
 

I mean that complex structure of modern files can lead to random modification 
of small file's parts.

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-12 Thread Jaegeuk Kim

2012-10-12 (금), 16:30 +0400, Vyacheslav Dubeyko:
 On Wed, 2012-10-10 at 18:43 +0900, Jaegeuk Kim wrote:
  [snip]
How about the following scenario?
1. data a is newly written.
2. checkpoint A is done.
3. data a is truncated.
4. checkpoint B is done.
   
If fs supports multiple snapshots like A and B to users, it cannot 
reuse the space allocated by
data a after checkpoint B even though data a is safely truncated 
by checkpoint B.
This is because fs should keep data a to prepare a roll-back to A.
So, even though user sees some free space, LFS may suffer from cleaning 
due to the exhausted free
   space.
If users want to avoid this, they have to remove snapshots by 
themselves. Or, maybe automatically?
   
   
   I feel that here it exists some misunderstanding in checkpoint/snapshot 
   terminology (especially, for
   the NILFS2 case). It is possible that NILFS2 volume can contain only 
   checkpoints (if user doesn't
   created any snapshot). You are right, snapshot cannot be deleted because, 
   in other word, user marked
   this file system state as important point. But checkpoints can be 
   reclaimed easily. I can't see any
   problem to reclaim free space from checkpoints in above-mentioned 
   scenario in the case of NILFS2. But
  
  I meant that snapshot does checkpoint.
  And, the problem is related to real file system utilization managed by 
  NILFS2.
   [fs utilization to users]   [fs utilization managed by 
  NILFS2]
  X - 1   X - 1
  1. new data aXX
  2. snapshot AXX
  3. truncate aX - 1   X
  4. snapshot BX - 1   X
  
  After this, user can see X-1, but the performance will be affected by X.
  Until the snapshot A is removed, user will experience the performance 
  determined by X.
  Do I misunderstand?
  
 
 Ok. Maybe I have some misunderstanding but checkpoint and snapshot are 
 different things for me (especially, in the case of NILFS2). :-)
 
 The most important is that f2fs has more efficient scheme of working with 
 checkpoints, from your point of view. If you are right then it is very good. 
 And I need to be more familiar with f2fs code.
 

Ok, thanks.

 [snip]
   As I know, NILFS2 has Garbage Collector that removes checkpoints 
   automatically in background. But it
   is possible also to force removing as checkpoints as snapshots by hands 
   with special utility using. As
  
  If users may not want to remove the snapshots automatically, should they 
  configure not to do this too?
  
 
 As I know, NILFS2 doesn't delete snapshots automatically but checkpoints - 
 yes. Moreover, it exists nilfs_cleanerd.conf configuration file that makes 
 possible to manage by NILFS cleanerd daemon's behavior (min/max number of 
 clean segments, selection policy, check/clean intervals and so on).
 

Ok.

 [snip]
IMHO, user does not need to know how many snapshots there exist and 
track the fs utilization all the
   time.
(off list: I don't know why cleaning process should be tuned by users.)
   
   
   What do you plan to do in the case of users' complains about issues with 
   free space reclaiming? If
   user doesn't know about checkpoints and haven't any tools for accessing 
   to checkpoints then how is it
   possible to investigate issues with free space reclaiming on an user side?
  
  Could you explain why reclaiming free space is an issue?
  IMHO, that issue is caused by adopting multiple snapshots.
  
 
 I didn't mean that reclaiming free space is an issue. I hope that f2fs
 is stable but unfortunately it is not possible for any software to be
 completely without bugs. So, anyway, f2fs users can have some issues
 during using. One of the possible issue can be unexpected situation
 with not reclaiming of free space. So, my question was about
 possibility to investigate such bug on the user's side. From my point
 of view, NILFS2 has very good utilities for such investigation.

You mean fsck?
Of course, we've implemented fsck tool also.
But, why I didn't open it is that code is a mess.
Another reason is that current fsck tool only checks
the consistency of f2fs.
Now we're still working on it to open.

 
 [snip]
In our experiments *also* on android phones, we've seen many random 
patterns with frequent fsync
   calls.
We found that the main problem is database, and I think f2fs is 
beneficial to this.
   
   I think that database is not main use-case on Android phones. The 
   dominating use-case can be operation
   by multimedia information and operations with small files, from my point 
   of view.
   
   So, it is possible to extract such key points from the shared paper: (1) 
   file has complex structure;
   (2) sequential access is not sequential; (3) auxiliary files dominate; 
   (4) multiple

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Wednesday 10 October 2012 00:53:51 Theodore Ts'o wrote:
 On Tue, Oct 09, 2012 at 01:01:24PM +0200, Lukáš Czerner wrote:
  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.
 
 A number of us has been telling flash vendors exactly this.  The
 technical people do seem to understand.  It's management who seem to
 be primarily clueless, even though this information can be extracted
 by employing timing attacks on the media.  I've pointed this out
 before, and the technical people agree that trying to keep this
 information as a trade secret is pointless, stupid, and
 counterproductive.  Trying to get the pointy-haired bosses to
 understand may take quite a while.

For eMMC, I think we should start out defaulting to the characteristics
that are reported by the device, because they are usually correct
and those vendors for which that is not true can hopefully
come to their senses when they see how f2fs performs by default.

For USB media, the protocol does not allow you to specify the
erase block size, so we have to guess.

For SD cards, there is a field in the card's registers, but I've
never seen any value in there other than 4 MB, and in most cases
where that is not true, the standard does not allow encoding
the correct amount: it only allows power-of-two numbers up to
4 MB, and typical numbers these days are 3 MB, 6 MB or 8 MB.

Arnd
--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Wednesday 10 October 2012 11:36:14 David Woodhouse wrote:
 The whole thing is silly. What we actually want on an embedded system is
 to ditch the FTL altogether and have direct access to the NAND. Then we
 can know our file system is behaving optimally. And we don't need
 hacks like TRIM to try to make things a little less broken.

I think it's safe to say that the times for raw flash in consumer devices
are over, whether we like it or not. Even if we could go back to MTD
for internal storage, we'd still need something better than what we
have for removable flash storage such as USB and SD.

(and I know that xD cards are basically raw flash, but have you tried
to buy one recently?)

Arnd
--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-10 Thread Namjae Jeon

2012/10/10 Jaegeuk Kim :

>>
>> I mean that every volume is placed inside any partition (MTD or GPT). Every 
>> partition begins from any
>> physical sector. So, as I can understand, f2fs volume can begin from 
>> physical sector that is laid
>> inside physical erase block. Thereby, in such case of formating the f2fs's 
>> operation units will be
>> unaligned in relation of physical erase blocks, from my point of view. 
>> Maybe, I misunderstand
>> something but it can lead to additional FTL operations and performance 
>> degradation, from my point of
>> view.
>
> I think mkfs already calculates the offset to align that.
I think this answer is not what he want.
If you don't use partition table such as dos partition table or gpt, I
think that it is possible to align using mkfs.
But If we should consider partition table space in storage, I don't
understand how it  could be align using mkfs.

Thanks.
> Thanks,
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-10 Thread David Woodhouse

On Tue, 2012-10-09 at 10:31 +0200, Lukáš Czerner wrote:
> 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.
> 
> 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.

The whole thing is silly. What we actually want on an embedded system is
to ditch the FTL altogether and have direct access to the NAND. Then we
can *know* our file system is behaving optimally. And we don't need
hacks like TRIM to try to make things a little less broken.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-10 Thread Jaegeuk Kim

[snip]
> > How about the following scenario?
> > 1. data "a" is newly written.
> > 2. checkpoint "A" is done.
> > 3. data "a" is truncated.
> > 4. checkpoint "B" is done.
> >
> > If fs supports multiple snapshots like "A" and "B" to users, it cannot 
> > reuse the space allocated by
> > data "a" after checkpoint "B" even though data "a" is safely truncated by 
> > checkpoint "B".
> > This is because fs should keep data "a" to prepare a roll-back to "A".
> > So, even though user sees some free space, LFS may suffer from cleaning due 
> > to the exhausted free
> space.
> > If users want to avoid this, they have to remove snapshots by themselves. 
> > Or, maybe automatically?
> >
> 
> I feel that here it exists some misunderstanding in checkpoint/snapshot 
> terminology (especially, for
> the NILFS2 case). It is possible that NILFS2 volume can contain only 
> checkpoints (if user doesn't
> created any snapshot). You are right, snapshot cannot be deleted because, in 
> other word, user marked
> this file system state as important point. But checkpoints can be reclaimed 
> easily. I can't see any
> problem to reclaim free space from checkpoints in above-mentioned scenario in 
> the case of NILFS2. But

I meant that snapshot does checkpoint.
And, the problem is related to real file system utilization managed by NILFS2.
 [fs utilization to users]   [fs utilization managed by 
NILFS2]
X - 1   X - 1
1. new data "a"XX
2. snapshot "A"XX
3. truncate "a"X - 1   X
4. snapshot "B"X - 1   X

After this, user can see X-1, but the performance will be affected by X.
Until the snapshot "A" is removed, user will experience the performance 
determined by X.
Do I misunderstand?

> if a user decides to make a snapshot then it is a law.
> 

I don't believe users can do all the things perfectly.

> So, from my point of view, f2fs volume contains only checkpoints without 
> possibility freeze some of it
> as snapshot. The f2fs volume contains checkpoints also but user can't touch 
> it in some way.
> 

Right.

> As I know, NILFS2 has Garbage Collector that removes checkpoints 
> automatically in background. But it
> is possible also to force removing as checkpoints as snapshots by hands with 
> special utility using. As

If users may not want to remove the snapshots automatically, should they 
configure not to do this too?

> I can understand, f2fs has Garbage Collector also that reclaims free space of 
> dirty checkpoints. So,
> what is the difference? I have such opinion that difference is in lack of 
> easy manipulation by
> checkpoints in the case of f2fs.

The problem that I concerned was performance degradation due to the real 
utilization available to the file system.

> 
> > >
> > > Moreover, user can't manage by f2fs checkpoints completely, as I can 
> > > understand. It is not so
> clear
> > > what critical points can be a starting points of recovery actions. How is 
> > > it possible to define
> how
> > > many checkpoints f2fs volume will have?
> >
> > IMHO, user does not need to know how many snapshots there exist and track 
> > the fs utilization all the
> time.
> > (off list: I don't know why cleaning process should be tuned by users.)
> >
> 
> What do you plan to do in the case of users' complains about issues with free 
> space reclaiming? If
> user doesn't know about checkpoints and haven't any tools for accessing to 
> checkpoints then how is it
> possible to investigate issues with free space reclaiming on an user side?

Could you explain why reclaiming free space is an issue?
IMHO, that issue is caused by adopting multiple snapshots.

[snip]

> 
> So, as I can understand, f2fs can be recovered by driver in the case of 
> validity of one from two
> checkpoints. Sudden power-off can occur anytime. How high probability to 
> achieve unrecoverable by
> driver state of f2fs during sudden power-off? Is it possible to recover f2fs 
> in such case by fsck, for

In order to avoid that case, f2fs minimizes data writes and carefully 
overwrites some of them during roll-forward.

> example?
> 
> > > >
> > > >> 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 
> > > > fsync overhead.
> > > >
> > >
> > > Yes, it can be so for the case of non-aged f2fs volume. But I am afraid 
> > > that for the case of aged
> f2fs
> > > volume the situation can be opposite. I think that in the case of aged 
> > > state of f2fs volume the GC
> > > will be under hard work in above-mentioned

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Tue, Oct 09, 2012 at 02:53:26PM -0500, Jooyoung Hwang wrote:

> I'd like you to refer to the following link as well which is about
> mobile workload pattern.
> http://www.cs.cmu.edu/~fuyaoz/courses/15712/report.pdf
> It's reported that in Android there are frequent issues of fsync and
> most of them are only for small size of data.

What bothers me is no one is asking the question, *why* is Android
(and more specifically SQLite and the applications which call SQLite)
using fsync's so often?  These aren't transaction processing systems,
after all.  So there are two questions that are worth asking here.
(a) Is SQLite being as flash-friendly as possible, and (b) do the
applications really need as many transaction boundaries as they are
requesting of SQLite.

Yes, we can optimize the file system, but sometimes the best way to
optimize a write is to not to do the write at all (if it is not
required for the application's functionality, of course).  If the
application is requesting 4 transaction boundaries where only one is
required, we can try to make fsync's more efficient, yes --- but there
is only so much that can be done at the fs layer.

- Ted
--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Tue, Oct 09, 2012 at 01:01:24PM +0200, Lukáš Czerner wrote:
> 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.

A number of us has been telling flash vendors exactly this.  The
technical people do seem to understand.  It's management who seem to
be primarily clueless, even though this information can be extracted
by employing timing attacks on the media.  I've pointed this out
before, and the technical people agree that trying to keep this
information as a "trade secret" is pointless, stupid, and
counterproductive.  Trying to get the pointy-haired bosses to
understand may take quite a while.

That being said, in many cases, it doesn't really matter.  For
example, if a manufacturer has a production run of a million Android
mobile devices, (a) all of the eMMC devices will be the same (or at
least come from a handful of suppliers in the worst case), and (b) the
menufacturers *will* be able to get this information under NDA, and so
they can just feed it straight to the mkfs program.  There's no need
in many cases to have mkfs burn write cycles carrying out a timing
attack on which flash device that it is formatting.

My concern is a different one.  We shouldn't just be focusing on
sqlite performance assuming that its characteristics are fixed, to the
point where it drives file system design and benchmarking.  Currently
sqllite does a lot of pointless writes at every single transaction
boundary which could be optimized if you relax the design constraint
that the database has to be in a single file --- something which is a
nice-to-have for some applications, but which really doesn't matter in
an embedded/mobile handset use case.

It may very well be that f2fs is still going to be better since it is
trying to minimize the number of erase blocks that are "open" for
writing at one time.  And even if eMMC devices become more
intelligent, optimizing for erase blocks is still a good thing
(although it may not result in as spectacular wins on flash devices
with more sophisticated FTL's.).

However, it may also be that we'll be able to teach some existing file
systme how to be more intelligent about optimizing for erase blocks
that could be made production stable faster.  (I have some ideas of
how to do this for ext4.)

But the point I'm trying to drive home here is that we shouldn't
assume that the only thing we can do is do optimize the file system.
Given the amount of time it takes to test, performance tune, and
confidence that the file system is sound and stable (look at how long
btrfs has taken to mature), it is likely that both flash technology
and workload characteristics will change before f2fs is fully mature
--- and this is no slight on the good work Jaegeuk and his team have
done.

Long experience with file systems show us that they are like fine
wine; they take time to mature.  Whether you're talking about
ext2/3/4, btrfs, Sun's ZFS, Digital's ADVFS, IBM's JFS or GPFS etc.,
and whether you're talking about file systems developed using open
source or more traditional corporate development processes, it takes a
minimum of 3-5 years and 50-200 PY's of effort to create a fully
production-ready file system from scratch (and some of the people
which I surveyed for the Nxxt Generation File System task force, some
of which had decades of experience creating and working with file
systems, thought the 50-75 Person-Year estimate was a lowball --- note
that Sun's ZFS took *seven* years to develop, even with a generously
staffed team.)

As an open source example, the NGFS system task force, decided to
claim, in its November 2007 report-out, that btrfs would be ready for
community distro's in two years, since otherwise the managers and
other folks who control corporate budgets at the companies involved
would be scared off and decide not to fund the project.  And yet here
we are in 2012, five years later, and we're just starting to see btrfs
support show up in community distro's as a supported option, and I
don't think most people would claim it is ready for production use in
enterprise distro's yet.

Given that, we might as well make sure we can do what we can to
optimize performance up and down the storage stack --- not just at the
file system level, but also by optimizing sqlite for embedded/handset
use cases.

Regards,

- Ted
--
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/

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Tue, 2012-10-09 at 14:53 -0500, Jooyoung Hwang wrote:
> On Tue, 2012-10-09 at 16:08 +0900, Jaegeuk Kim wrote:
> > > -Original Message-
> > > From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> > > Sent: Tuesday, October 09, 2012 4:23 AM
> > > To: Jaegeuk Kim
> > > Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
> > > gre...@linuxfoundation.org; linux-
> > > ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
> > > jooyoung.hw...@samsung.com;
> > > linux-fsde...@vger.kernel.org
> > > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

> 
> I'd like you to refer to the following link as well which is about
> mobile workload pattern.
> http://www.cs.cmu.edu/~fuyaoz/courses/15712/report.pdf
> It's reported that in Android there are frequent issues of fsync and
> most of them are only for small size of data.
> 
> To provide efficient fsync, F2FS minimizes the amount of metadata
> written to serve a fsync. Fsync in F2FS is completed by writing user
> data blocks and direct node blocks which point to them rather than
> creating a new checkpoint which would incur more I/O loads. 
> If sudden power failure happens, then F2FS recovery routine rolls back
> to the latest checkpoint and thereafter recovers file system state to
> reflect all the completed fsync operations, which we call roll-forward
> recovery.
> You may want to look at the code about the roll-forward in 
> recover_fsync_data().
> 

Thank you.

With the best regards,
Vyacheslav Dubeyko.

> --
> Jooyoung Hwang
> Samsung Electronics
> 
> --
> 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/


--
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/

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Tue, 2012-10-09 at 16:08 +0900, Jaegeuk Kim wrote:
> > -Original Message-
> > From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> > Sent: Tuesday, October 09, 2012 4:23 AM
> > To: Jaegeuk Kim
> > Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
> > gre...@linuxfoundation.org; linux-
> > ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
> > jooyoung.hw...@samsung.com;
> > linux-fsde...@vger.kernel.org
> > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

> > >>> 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 functionalities.
> > >>>
> > >>
> > >> Performance is a good goal. But fault-tolerance is also very important 
> > >> point. Filesystems are used
> > by
> > >> users, so, it is very important to guarantee reliability of data 
> > >> keeping. Degradation of
> > performance
> > >> by means of snapshots is arguable point. Snapshots can solve the problem 
> > >> 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 should 
> > > 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 snapshot 
> > > feature is also a good
> > alternative approach.
> > > That may be a trade-off.
> > 
> > So, maybe I misunderstand something, but I can't understand the difference. 
> > As I know, snapshot in
> > NILFS2 is a checkpoint converted by user in snapshot. So, NILFS2's 
> > checkpoint is a log that adds new
> > file system's state changing (user data + metadata). In other words, 
> > checkpoint is mechanism of
> > writing on volume. Moreover, NILFS2 gives flexible way of 
> > checkpoint/snapshot management.
> > 
> > As you are saying, f2fs supports checkpoints also. It means for me that 
> > checkpoints are the basic
> > mechanism of writing operations on f2fs. But, about what performance gain 
> > and difference do you talk?
> 
> How about the following scenario?
> 1. data "a" is newly written.
> 2. checkpoint "A" is done.
> 3. data "a" is truncated.
> 4. checkpoint "B" is done.
> 
> If fs supports multiple snapshots like "A" and "B" to users, it cannot reuse 
> the space allocated by
> data "a" after checkpoint "B" even though data "a" is safely truncated by 
> checkpoint "B".
> This is because fs should keep data "a" to prepare a roll-back to "A".
> So, even though user sees some free space, LFS may suffer from cleaning due 
> to the exhausted free space.
> If users want to avoid this, they have to remove snapshots by themselves. Or, 
> maybe automatically?
> 

I feel that here it exists some misunderstanding in checkpoint/snapshot 
terminology (especially, for the NILFS2 case). It is possible that NILFS2 
volume can contain only checkpoints (if user doesn't created any snapshot). You 
are right, snapshot cannot be deleted because, in other word, user marked this 
file system state as important point. But checkpoints can be reclaimed easily. 
I can't see any problem to reclaim free space from checkpoints in 
above-mentioned scenario in the case of NILFS2. But if a user decides to make a 
snapshot then it is a law.  

So, from my point of view, f2fs volume contains only checkpoints without 
possibility freeze some of it as snapshot. The f2fs volume contains checkpoints 
also but user can't touch it in some way.

As I know, NILFS2 has Garbage Collector that removes checkpoints automatically 
in background. But it is possible also to force removing as checkpoints as 
snapshots by hands with special utility using. As I can understand, f2fs has 
Garbage Collector also that reclaims free space of dirty checkpoints. So, what 
is the difference? I have such opinion that difference is in lack of easy 
manipulation

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Tue, 2012-10-09 at 16:08 +0900, Jaegeuk Kim wrote:
  -Original Message-
  From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
  Sent: Tuesday, October 09, 2012 4:23 AM
  To: Jaegeuk Kim
  Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
  gre...@linuxfoundation.org; linux-
  ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
  jooyoung.hw...@samsung.com;
  linux-fsde...@vger.kernel.org
  Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

   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 functionalities.

   Performance is a good goal. But fault-tolerance is also very important 
   point. Filesystems are used
  by
   users, so, it is very important to guarantee reliability of data 
   keeping. Degradation of
  performance
   by means of snapshots is arguable point. Snapshots can solve the problem 
   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 should 
   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 snapshot 
   feature is also a good
  alternative approach.
   That may be a trade-off.

  So, maybe I misunderstand something, but I can't understand the difference. 
  As I know, snapshot in
  NILFS2 is a checkpoint converted by user in snapshot. So, NILFS2's 
  checkpoint is a log that adds new
  file system's state changing (user data + metadata). In other words, 
  checkpoint is mechanism of
  writing on volume. Moreover, NILFS2 gives flexible way of 
  checkpoint/snapshot management.

  As you are saying, f2fs supports checkpoints also. It means for me that 
  checkpoints are the basic
  mechanism of writing operations on f2fs. But, about what performance gain 
  and difference do you talk?

 How about the following scenario?
 1. data a is newly written.
 2. checkpoint A is done.
 3. data a is truncated.
 4. checkpoint B is done.

 If fs supports multiple snapshots like A and B to users, it cannot reuse 
 the space allocated by
 data a after checkpoint B even though data a is safely truncated by 
 checkpoint B.
 This is because fs should keep data a to prepare a roll-back to A.
 So, even though user sees some free space, LFS may suffer from cleaning due 
 to the exhausted free space.
 If users want to avoid this, they have to remove snapshots by themselves. Or, 
 maybe automatically?

I feel that here it exists some misunderstanding in checkpoint/snapshot 
terminology (especially, for the NILFS2 case). It is possible that NILFS2 
volume can contain only checkpoints (if user doesn't created any snapshot). You 
are right, snapshot cannot be deleted because, in other word, user marked this 
file system state as important point. But checkpoints can be reclaimed easily. 
I can't see any problem to reclaim free space from checkpoints in 
above-mentioned scenario in the case of NILFS2. But if a user decides to make a 
snapshot then it is a law.  

So, from my point of view, f2fs volume contains only checkpoints without 
possibility freeze some of it as snapshot. The f2fs volume contains checkpoints 
also but user can't touch it in some way.

As I know, NILFS2 has Garbage Collector that removes checkpoints automatically 
in background. But it is possible also to force removing as checkpoints as 
snapshots by hands with special utility using. As I can understand, f2fs has 
Garbage Collector also that reclaims free space of dirty checkpoints. So, what 
is the difference? I have such opinion that difference is in lack of easy 
manipulation by checkpoints in the case of f2fs.

  Moreover, user can't manage by f2fs checkpoints completely, as I can 
  understand. It is not so clear
  what critical points can be a starting points of recovery actions. How is 
  it possible to define how
  many checkpoints f2fs volume will have?

 IMHO, user does not need to know how many snapshots there exist and track the 
 fs utilization all the time.
 (off list: I don't know why cleaning process should be tuned by users.)

What do you plan to do in the case of users' complains about issues with free 
space reclaiming? If user doesn't know about checkpoints and haven't any tools 
for accessing to checkpoints then how is it possible to investigate issues with 
free space reclaiming on an user side?

 f2fs writes two checkpoints alternatively. One is for the last stable 
 checkpoint

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Tue, 2012-10-09 at 14:53 -0500, Jooyoung Hwang wrote:
 On Tue, 2012-10-09 at 16:08 +0900, Jaegeuk Kim wrote:
   -Original Message-
   From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
   Sent: Tuesday, October 09, 2012 4:23 AM
   To: Jaegeuk Kim
   Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
   gre...@linuxfoundation.org; linux-
   ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
   jooyoung.hw...@samsung.com;
   linux-fsde...@vger.kernel.org
   Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 I'd like you to refer to the following link as well which is about
 mobile workload pattern.
 http://www.cs.cmu.edu/~fuyaoz/courses/15712/report.pdf
 It's reported that in Android there are frequent issues of fsync and
 most of them are only for small size of data.

 To provide efficient fsync, F2FS minimizes the amount of metadata
 written to serve a fsync. Fsync in F2FS is completed by writing user
 data blocks and direct node blocks which point to them rather than
 creating a new checkpoint which would incur more I/O loads. 
 If sudden power failure happens, then F2FS recovery routine rolls back
 to the latest checkpoint and thereafter recovers file system state to
 reflect all the completed fsync operations, which we call roll-forward
 recovery.
 You may want to look at the code about the roll-forward in 
 recover_fsync_data().

Thank you.

With the best regards,
Vyacheslav Dubeyko.

 --
 Jooyoung Hwang
 Samsung Electronics

 --
 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/

--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Tue, Oct 09, 2012 at 01:01:24PM +0200, Lukáš Czerner wrote:
 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.

A number of us has been telling flash vendors exactly this.  The
technical people do seem to understand.  It's management who seem to
be primarily clueless, even though this information can be extracted
by employing timing attacks on the media.  I've pointed this out
before, and the technical people agree that trying to keep this
information as a trade secret is pointless, stupid, and
counterproductive.  Trying to get the pointy-haired bosses to
understand may take quite a while.

That being said, in many cases, it doesn't really matter.  For
example, if a manufacturer has a production run of a million Android
mobile devices, (a) all of the eMMC devices will be the same (or at
least come from a handful of suppliers in the worst case), and (b) the
menufacturers *will* be able to get this information under NDA, and so
they can just feed it straight to the mkfs program.  There's no need
in many cases to have mkfs burn write cycles carrying out a timing
attack on which flash device that it is formatting.


My concern is a different one.  We shouldn't just be focusing on
sqlite performance assuming that its characteristics are fixed, to the
point where it drives file system design and benchmarking.  Currently
sqllite does a lot of pointless writes at every single transaction
boundary which could be optimized if you relax the design constraint
that the database has to be in a single file --- something which is a
nice-to-have for some applications, but which really doesn't matter in
an embedded/mobile handset use case.

It may very well be that f2fs is still going to be better since it is
trying to minimize the number of erase blocks that are open for
writing at one time.  And even if eMMC devices become more
intelligent, optimizing for erase blocks is still a good thing
(although it may not result in as spectacular wins on flash devices
with more sophisticated FTL's.).

However, it may also be that we'll be able to teach some existing file
systme how to be more intelligent about optimizing for erase blocks
that could be made production stable faster.  (I have some ideas of
how to do this for ext4.)

But the point I'm trying to drive home here is that we shouldn't
assume that the only thing we can do is do optimize the file system.
Given the amount of time it takes to test, performance tune, and
confidence that the file system is sound and stable (look at how long
btrfs has taken to mature), it is likely that both flash technology
and workload characteristics will change before f2fs is fully mature
--- and this is no slight on the good work Jaegeuk and his team have
done.

Long experience with file systems show us that they are like fine
wine; they take time to mature.  Whether you're talking about
ext2/3/4, btrfs, Sun's ZFS, Digital's ADVFS, IBM's JFS or GPFS etc.,
and whether you're talking about file systems developed using open
source or more traditional corporate development processes, it takes a
minimum of 3-5 years and 50-200 PY's of effort to create a fully
production-ready file system from scratch (and some of the people
which I surveyed for the Nxxt Generation File System task force, some
of which had decades of experience creating and working with file
systems, thought the 50-75 Person-Year estimate was a lowball --- note
that Sun's ZFS took *seven* years to develop, even with a generously
staffed team.)

As an open source example, the NGFS system task force, decided to
claim, in its November 2007 report-out, that btrfs would be ready for
community distro's in two years, since otherwise the managers and
other folks who control corporate budgets at the companies involved
would be scared off and decide not to fund the project.  And yet here
we are in 2012, five years later, and we're just starting to see btrfs
support show up in community distro's as a supported option, and I
don't think most people would claim it is ready for production use in
enterprise distro's yet.

Given that, we might as well make sure we can do what we can to
optimize performance up and down the storage stack --- not just at the
file system level, but also by optimizing sqlite for embedded/handset
use cases.

Regards,

- Ted
--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Tue, Oct 09, 2012 at 02:53:26PM -0500, Jooyoung Hwang wrote:

 I'd like you to refer to the following link as well which is about
 mobile workload pattern.
 http://www.cs.cmu.edu/~fuyaoz/courses/15712/report.pdf
 It's reported that in Android there are frequent issues of fsync and
 most of them are only for small size of data.

What bothers me is no one is asking the question, *why* is Android
(and more specifically SQLite and the applications which call SQLite)
using fsync's so often?  These aren't transaction processing systems,
after all.  So there are two questions that are worth asking here.
(a) Is SQLite being as flash-friendly as possible, and (b) do the
applications really need as many transaction boundaries as they are
requesting of SQLite.

Yes, we can optimize the file system, but sometimes the best way to
optimize a write is to not to do the write at all (if it is not
required for the application's functionality, of course).  If the
application is requesting 4 transaction boundaries where only one is
required, we can try to make fsync's more efficient, yes --- but there
is only so much that can be done at the fs layer.

- Ted
--
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/

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-10 Thread Jaegeuk Kim

[snip]
  How about the following scenario?
  1. data a is newly written.
  2. checkpoint A is done.
  3. data a is truncated.
  4. checkpoint B is done.
 
  If fs supports multiple snapshots like A and B to users, it cannot 
  reuse the space allocated by
  data a after checkpoint B even though data a is safely truncated by 
  checkpoint B.
  This is because fs should keep data a to prepare a roll-back to A.
  So, even though user sees some free space, LFS may suffer from cleaning due 
  to the exhausted free
 space.
  If users want to avoid this, they have to remove snapshots by themselves. 
  Or, maybe automatically?
 
 
 I feel that here it exists some misunderstanding in checkpoint/snapshot 
 terminology (especially, for
 the NILFS2 case). It is possible that NILFS2 volume can contain only 
 checkpoints (if user doesn't
 created any snapshot). You are right, snapshot cannot be deleted because, in 
 other word, user marked
 this file system state as important point. But checkpoints can be reclaimed 
 easily. I can't see any
 problem to reclaim free space from checkpoints in above-mentioned scenario in 
 the case of NILFS2. But

I meant that snapshot does checkpoint.
And, the problem is related to real file system utilization managed by NILFS2.
 [fs utilization to users]   [fs utilization managed by 
NILFS2]
X - 1   X - 1
1. new data aXX
2. snapshot AXX
3. truncate aX - 1   X
4. snapshot BX - 1   X

After this, user can see X-1, but the performance will be affected by X.
Until the snapshot A is removed, user will experience the performance 
determined by X.
Do I misunderstand?

 if a user decides to make a snapshot then it is a law.
 

I don't believe users can do all the things perfectly.

 So, from my point of view, f2fs volume contains only checkpoints without 
 possibility freeze some of it
 as snapshot. The f2fs volume contains checkpoints also but user can't touch 
 it in some way.
 

Right.

 As I know, NILFS2 has Garbage Collector that removes checkpoints 
 automatically in background. But it
 is possible also to force removing as checkpoints as snapshots by hands with 
 special utility using. As

If users may not want to remove the snapshots automatically, should they 
configure not to do this too?

 I can understand, f2fs has Garbage Collector also that reclaims free space of 
 dirty checkpoints. So,
 what is the difference? I have such opinion that difference is in lack of 
 easy manipulation by
 checkpoints in the case of f2fs.

The problem that I concerned was performance degradation due to the real 
utilization available to the file system.

 
  
   Moreover, user can't manage by f2fs checkpoints completely, as I can 
   understand. It is not so
 clear
   what critical points can be a starting points of recovery actions. How is 
   it possible to define
 how
   many checkpoints f2fs volume will have?
 
  IMHO, user does not need to know how many snapshots there exist and track 
  the fs utilization all the
 time.
  (off list: I don't know why cleaning process should be tuned by users.)
 
 
 What do you plan to do in the case of users' complains about issues with free 
 space reclaiming? If
 user doesn't know about checkpoints and haven't any tools for accessing to 
 checkpoints then how is it
 possible to investigate issues with free space reclaiming on an user side?

Could you explain why reclaiming free space is an issue?
IMHO, that issue is caused by adopting multiple snapshots.

[snip]

 
 So, as I can understand, f2fs can be recovered by driver in the case of 
 validity of one from two
 checkpoints. Sudden power-off can occur anytime. How high probability to 
 achieve unrecoverable by
 driver state of f2fs during sudden power-off? Is it possible to recover f2fs 
 in such case by fsck, for

In order to avoid that case, f2fs minimizes data writes and carefully 
overwrites some of them during roll-forward.

 example?
 
   
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 
fsync overhead.
   
  
   Yes, it can be so for the case of non-aged f2fs volume. But I am afraid 
   that for the case of aged
 f2fs
   volume the situation can be opposite. I think that in the case of aged 
   state of f2fs volume the GC
   will be under hard work in above-mentioned workloads.
 
  Yes, you're right.
  In the LFS paper above, there are two logging schemes: threaded logging and 
  copy-and-compaction.
  In order to avoid high cleaning overhead, f2fs adopts a hybrid one which

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-10 Thread David Woodhouse

On Tue, 2012-10-09 at 10:31 +0200, Lukáš Czerner wrote:
 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.
 
 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.

The whole thing is silly. What we actually want on an embedded system is
to ditch the FTL altogether and have direct access to the NAND. Then we
can *know* our file system is behaving optimally. And we don't need
hacks like TRIM to try to make things a little less broken.

-- 
dwmw2


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-10 Thread Namjae Jeon

2012/10/10 Jaegeuk Kim jaegeuk@samsung.com:


 I mean that every volume is placed inside any partition (MTD or GPT). Every 
 partition begins from any
 physical sector. So, as I can understand, f2fs volume can begin from 
 physical sector that is laid
 inside physical erase block. Thereby, in such case of formating the f2fs's 
 operation units will be
 unaligned in relation of physical erase blocks, from my point of view. 
 Maybe, I misunderstand
 something but it can lead to additional FTL operations and performance 
 degradation, from my point of
 view.

 I think mkfs already calculates the offset to align that.
I think this answer is not what he want.
If you don't use partition table such as dos partition table or gpt, I
think that it is possible to align using mkfs.
But If we should consider partition table space in storage, I don't
understand how it  could be align using mkfs.

Thanks.
 Thanks,

 --
 To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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/

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

> -Original Message-
> From: linux-fsdevel-ow...@vger.kernel.org 
> [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of
> Dave Chinner
> Sent: Wednesday, October 10, 2012 6:20 AM
> To: Jaegeuk Kim
> Cc: 'Lukáš Czerner'; 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 
> 'Jaegeuk Kim'; 'Al Viro';
> ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> chur@samsung.com;
> cm224@samsung.com; jooyoung.hw...@samsung.com; 
> linux-fsde...@vger.kernel.org
> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> 
> [ Folks, can you trim your responses down to just quote the part you
> are responding to? Having to repeatedly scroll through 500 lines of
> irrelevant text just to find the 5 lines that is being commented on
> is exceedingly painful.  ]

Ok, I'll keep in mind.
Thanks.

> 
> On Tue, Oct 09, 2012 at 09:01:18PM +0900, Jaegeuk Kim wrote:
> > > From: Lukáš Czerner [mailto:lczer...@redhat.com]
> > > > > 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.
> 
> And in response, other people are "suggesting" that this is the
> wrong approach.

Ok, it makes sense.
I agree that the Linaro survey has been well proceeded, and no more heuristic 
is needed.

> 
> > > > 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.
> 
> Linaro already have one, which is another reason why using
> heuristics is the wrong approach:
> 
> https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey?action=show=WorkingGrou
> ps%2FKernelConsolidation%2FProjects%2FFlashCardSurvey
> 
> > 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?
> 
> It's public information.
> 
> If you want to support different types of flash, then either add
> your timing attack derived information on specific hardware to the
> above table, or force vendors to update it themselves if they want
> their flash memory supported by this filesystem.

Sound good.
If I also get something, I'll try.
Thank you.
> 
> Cheers,
> 
> Dave.
> --
> Dave Chinner
> da...@fromorbit.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-09 Thread Dave Chinner

[ Folks, can you trim your responses down to just quote the part you
are responding to? Having to repeatedly scroll through 500 lines of
irrelevant text just to find the 5 lines that is being commented on
is exceedingly painful.  ]

On Tue, Oct 09, 2012 at 09:01:18PM +0900, Jaegeuk Kim wrote:
> > From: Lukáš Czerner [mailto:lczer...@redhat.com]
> > > > 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.

And in response, other people are "suggesting" that this is the
wrong approach.

> > > 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.

Linaro already have one, which is another reason why using
heuristics is the wrong approach:

https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey?action=show=WorkingGroups%2FKernelConsolidation%2FProjects%2FFlashCardSurvey

> 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?

It's public information.

If you want to support different types of flash, then either add
your timing attack derived information on specific hardware to the
above table, or force vendors to update it themselves if they want
their flash memory supported by this filesystem.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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/

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-09 Thread Jooyoung Hwang

On Tue, 2012-10-09 at 16:08 +0900, Jaegeuk Kim wrote:
> > -Original Message-
> > From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> > Sent: Tuesday, October 09, 2012 4:23 AM
> > To: Jaegeuk Kim
> > Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
> > gre...@linuxfoundation.org; linux-
> > ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
> > jooyoung.hw...@samsung.com;
> > linux-fsde...@vger.kernel.org
> > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > 
> > Hi,
> > 
> > On Oct 8, 2012, at 12:25 PM, Jaegeuk Kim wrote:
> > 
> > >> -Original Message-
> > >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> > >> Sent: Sunday, October 07, 2012 9:09 PM
> > >> To: Jaegeuk Kim
> > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
> > >> gre...@linuxfoundation.org; linux-
> > >> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
> > >> jooyoung.hw...@samsung.com;
> > >> linux-fsde...@vger.kernel.org
> > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > >>
> > >> Hi,
> > >>
> > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
> > >>
> > >>>> -Original Message-
> > >>>> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> > >>>> Sent: Sunday, October 07, 2012 4:10 PM
> > >>>> To: Jaegeuk Kim
> > >>>> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; 
> > >>>> ty...@mit.edu;
> > gre...@linuxfoundation.org;
> > >>>> linux-kernel@vger.kernel.org; chur@samsung.com; 
> > >>>> cm224@samsung.com;
> > >> jooyoung.hw...@samsung.com;
> > >>>> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
> > >>>>>> Hi Jaegeuk,
> > >>>>>
> > >>>>> Hi.
> > >>>>> We know each other, right? :)
> > >>>>>
> > >>>>>>
> > >>>>>>> From:   김재극 
> > >>>>>>> To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
> > >>>>>>> ,
> > >>>> 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 
> > >>>>>&g

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
> >

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

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

-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
--
To unsubscribe from

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

> -Original Message-
> From: Lukáš Czerner [mailto:lczer...@redhat.com]
> Sent: Tuesday, October 09, 2012 8:01 PM
> To: Jaegeuk Kim
> Cc: 'Lukáš Czerner'; 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 
> 'Jaegeuk Kim'; 'Al Viro';
> ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> chur@samsung.com;
> cm224@samsung.com; jooyoung.hw...@samsung.com; 
> linux-fsde...@vger.kernel.org
> Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> 
> On Tue, 9 Oct 2012, Jaegeuk Kim wrote:
> 
> > Date: Tue, 09 Oct 2012 19:45:57 +0900
> > From: Jaegeuk Kim 
> > To: 'Lukáš Czerner' 
> > Cc: 'Namjae Jeon' ,
> > 'Vyacheslav Dubeyko' ,
> > 'Marco Stornelli' ,
> > 'Jaegeuk Kim' ,
> > 'Al Viro' , ty...@mit.edu,
> > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
> > chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com,
> > linux-fsde...@vger.kernel.org
> > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> >
> > > -Original Message-
> > > From: linux-fsdevel-ow...@vger.kernel.org 
> > > [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf
> Of
> > > Luka? Czerner
> > > Sent: Tuesday, October 09, 2012 5:32 PM
> > > To: Jaegeuk Kim
> > > Cc: 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 'Jaegeuk 
> > > Kim'; 'Al Viro';
> ty...@mit.edu;
> > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> > > chur@samsung.com;
> cm224@samsung.com;
> > > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> > > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > >
> > > On Mon, 8 Oct 2012, Jaegeuk Kim wrote:
> > >
> > > > Date: Mon, 08 Oct 2012 19:52:03 +0900
> > > > From: Jaegeuk Kim 
> > > > To: 'Namjae Jeon' 
> > > > Cc: 'Vyacheslav Dubeyko' ,
> > > >     'Marco Stornelli' ,
> > > > 'Jaegeuk Kim' ,
> > > > 'Al Viro' , ty...@mit.edu,
> > > > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
> > > > chur@samsung.com, cm224@samsung.com, 
> > > > jooyoung.hw...@samsung.com,
> > > > linux-fsde...@vger.kernel.org
> > > > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > > >
> > > > > -Original Message-
> > > > > From: Namjae Jeon [mailto:linkinj...@gmail.com]
> > > > > Sent: Monday, October 08, 2012 7:00 PM
> > > > > To: Jaegeuk Kim
> > > > > Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; 
> > > > > ty...@mit.edu;
> > > > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> > > > > chur@samsung.com;
> > > cm224@samsung.com;
> > > > > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> > > > > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > > > >
> > > > > 2012/10/8, Jaegeuk Kim :
> > > > > >> -Original Message-
> > > > > >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> > > > > >> Sent: Sunday, October 07, 2012 9:09 PM
> > > > > >> To: Jaegeuk Kim
> > > > > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
> > > > > >> gre...@linuxfoundation.org; linux-
> > > > > >> ker...@vger.kernel.org; chur@samsung.com; 
> > > > > >> cm224@samsung.com;
> > > > > >> jooyoung.hw...@samsung.com;
> > > > > >> linux-fsde...@vger.kernel.org
> > > > > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file 
> > > > > >> system
> > > > > >>
> > > > > >> Hi,
> > > > > >>
> > > > > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
> > > > > >>
> > > > > >> >> -Original Message-
> > > > > >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> > > > > >> >> Sent: Sunday, October 07, 2012 4:10 PM
> > > > > >> >> To: Jaegeuk Kim
> > > > > >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
> > > > > >> >> ty...@mit.edu; gre...@linuxfoundation.or

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Tue, 9 Oct 2012, Jaegeuk Kim wrote:

> Date: Tue, 09 Oct 2012 19:45:57 +0900
> From: Jaegeuk Kim 
> To: 'Lukáš Czerner' 
> Cc: 'Namjae Jeon' ,
> 'Vyacheslav Dubeyko' ,
> 'Marco Stornelli' ,
> 'Jaegeuk Kim' ,
> 'Al Viro' , ty...@mit.edu,
> gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
> chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com,
> linux-fsde...@vger.kernel.org
> Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> 
> > -Original Message-
> > From: linux-fsdevel-ow...@vger.kernel.org 
> > [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of
> > Luka? Czerner
> > Sent: Tuesday, October 09, 2012 5:32 PM
> > To: Jaegeuk Kim
> > Cc: 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 'Jaegeuk Kim'; 
> > 'Al Viro'; ty...@mit.edu;
> > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> > chur@samsung.com; cm224@samsung.com;
> > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > 
> > On Mon, 8 Oct 2012, Jaegeuk Kim wrote:
> > 
> > > Date: Mon, 08 Oct 2012 19:52:03 +0900
> > > From: Jaegeuk Kim 
> > > To: 'Namjae Jeon' 
> > > Cc: 'Vyacheslav Dubeyko' ,
> > > 'Marco Stornelli' ,
> > > 'Jaegeuk Kim' ,
> > > 'Al Viro' , ty...@mit.edu,
> > > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
> > > chur@samsung.com, cm224@samsung.com, 
> > > jooyoung.hw...@samsung.com,
> > > linux-fsde...@vger.kernel.org
> > > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > >
> > > > -Original Message-
> > > > From: Namjae Jeon [mailto:linkinj...@gmail.com]
> > > > Sent: Monday, October 08, 2012 7:00 PM
> > > > To: Jaegeuk Kim
> > > > Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; 
> > > > ty...@mit.edu;
> > > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> > > > chur@samsung.com;
> > cm224@samsung.com;
> > > > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> > > > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > > >
> > > > 2012/10/8, Jaegeuk Kim :
> > > > >> -Original Message-
> > > > >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> > > > >> Sent: Sunday, October 07, 2012 9:09 PM
> > > > >> To: Jaegeuk Kim
> > > > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
> > > > >> gre...@linuxfoundation.org; linux-
> > > > >> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
> > > > >> jooyoung.hw...@samsung.com;
> > > > >> linux-fsde...@vger.kernel.org
> > > > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > > > >>
> > > > >> Hi,
> > > > >>
> > > > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
> > > > >>
> > > > >> >> -Original Message-
> > > > >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> > > > >> >> Sent: Sunday, October 07, 2012 4:10 PM
> > > > >> >> To: Jaegeuk Kim
> > > > >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
> > > > >> >> ty...@mit.edu; gre...@linuxfoundation.org;
> > > > >> >> linux-kernel@vger.kernel.org; chur@samsung.com;
> > > > >> >> cm224@samsung.com;
> > > > >> jooyoung.hw...@samsung.com;
> > > > >> >> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
> > > > >> >>>> Hi Jaegeuk,
> > > > >> >>>
> > > > >> >>> Hi.
> > > > >> >>> We know each other, right? :)
> > > > >> >>>
> > > > >> >>>>
> > > > >> >>>>>

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

> -Original Message-
> From: linux-fsdevel-ow...@vger.kernel.org 
> [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of
> Luka? Czerner
> Sent: Tuesday, October 09, 2012 5:32 PM
> To: Jaegeuk Kim
> Cc: 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 'Jaegeuk Kim'; 
> 'Al Viro'; ty...@mit.edu;
> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> chur@samsung.com; cm224@samsung.com;
> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> 
> On Mon, 8 Oct 2012, Jaegeuk Kim wrote:
> 
> > Date: Mon, 08 Oct 2012 19:52:03 +0900
> > From: Jaegeuk Kim 
> > To: 'Namjae Jeon' 
> > Cc: 'Vyacheslav Dubeyko' ,
> > 'Marco Stornelli' ,
> > 'Jaegeuk Kim' ,
> > 'Al Viro' , ty...@mit.edu,
> > gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
> > chur@samsung.com, cm224....@samsung.com, jooyoung.hw...@samsung.com,
> >     linux-fsde...@vger.kernel.org
> > Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> >
> > > -Original Message-
> > > From: Namjae Jeon [mailto:linkinj...@gmail.com]
> > > Sent: Monday, October 08, 2012 7:00 PM
> > > To: Jaegeuk Kim
> > > Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; 
> > > ty...@mit.edu;
> > > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> > > chur@samsung.com;
> cm224@samsung.com;
> > > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> > > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > >
> > > 2012/10/8, Jaegeuk Kim :
> > > >> -Original Message-
> > > >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> > > >> Sent: Sunday, October 07, 2012 9:09 PM
> > > >> To: Jaegeuk Kim
> > > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
> > > >> gre...@linuxfoundation.org; linux-
> > > >> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
> > > >> jooyoung.hw...@samsung.com;
> > > >> linux-fsde...@vger.kernel.org
> > > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > > >>
> > > >> Hi,
> > > >>
> > > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
> > > >>
> > > >> >> -Original Message-
> > > >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> > > >> >> Sent: Sunday, October 07, 2012 4:10 PM
> > > >> >> To: Jaegeuk Kim
> > > >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
> > > >> >> ty...@mit.edu; gre...@linuxfoundation.org;
> > > >> >> linux-kernel@vger.kernel.org; chur@samsung.com;
> > > >> >> cm224@samsung.com;
> > > >> jooyoung.hw...@samsung.com;
> > > >> >> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
> > > >> >>>> Hi Jaegeuk,
> > > >> >>>
> > > >> >>> Hi.
> > > >> >>> We know each other, right? :)
> > > >> >>>
> > > >> >>>>
> > > >> >>>>> From:김재극 
> > > >> >>>>> To:  v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
> > > >> >>>>> ,
> > > >> >> 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?

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Mon, 8 Oct 2012, Jaegeuk Kim wrote:

> Date: Mon, 08 Oct 2012 19:52:03 +0900
> From: Jaegeuk Kim 
> To: 'Namjae Jeon' 
> Cc: 'Vyacheslav Dubeyko' ,
> 'Marco Stornelli' ,
> 'Jaegeuk Kim' ,
> 'Al Viro' , ty...@mit.edu,
> gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
> chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com,
> linux-fsde...@vger.kernel.org
> Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
> 
> > -Original Message-
> > From: Namjae Jeon [mailto:linkinj...@gmail.com]
> > Sent: Monday, October 08, 2012 7:00 PM
> > To: Jaegeuk Kim
> > Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; 
> > ty...@mit.edu;
> > gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> > chur@samsung.com; cm224@samsung.com;
> > jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> > Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > 
> > 2012/10/8, Jaegeuk Kim :
> > >> -Original Message-
> > >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> > >> Sent: Sunday, October 07, 2012 9:09 PM
> > >> To: Jaegeuk Kim
> > >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
> > >> gre...@linuxfoundation.org; linux-
> > >> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
> > >> jooyoung.hw...@samsung.com;
> > >> linux-fsde...@vger.kernel.org
> > >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> > >>
> > >> Hi,
> > >>
> > >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
> > >>
> > >> >> -Original Message-
> > >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> > >> >> Sent: Sunday, October 07, 2012 4:10 PM
> > >> >> To: Jaegeuk Kim
> > >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
> > >> >> ty...@mit.edu; gre...@linuxfoundation.org;
> > >> >> linux-kernel@vger.kernel.org; chur@samsung.com;
> > >> >> cm224@samsung.com;
> > >> jooyoung.hw...@samsung.com;
> > >> >> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
> > >> >>>> Hi Jaegeuk,
> > >> >>>
> > >> >>> Hi.
> > >> >>> We know each other, right? :)
> > >> >>>
> > >> >>>>
> > >> >>>>> From:  김재극 
> > >> >>>>> To:v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
> > >> >>>>> ,
> > >> >> 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
> > >> >

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system



---
Jaegeuk Kim
Samsung


> -Original Message-
> From: Namjae Jeon [mailto:linkinj...@gmail.com]
> Sent: Tuesday, October 09, 2012 12:52 PM
> To: Jaegeuk Kim
> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; ty...@mit.edu;
> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> chur@samsung.com; cm224@samsung.com;
> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> 
> 2012/10/8, Jaegeuk Kim :
> >> -Original Message-
> >> From: Namjae Jeon [mailto:linkinj...@gmail.com]
> >> Sent: Monday, October 08, 2012 8:22 PM
> >> To: Jaegeuk Kim
> >> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
> >> ty...@mit.edu;
> >> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> >> chur@samsung.com; cm224....@samsung.com;
> >> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> >>
> >> 2012/10/8, Jaegeuk Kim :
> >> >> -Original Message-
> >> >> From: Namjae Jeon [mailto:linkinj...@gmail.com]
> >> >> Sent: Monday, October 08, 2012 7:00 PM
> >> >> To: Jaegeuk Kim
> >> >> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
> >> >> ty...@mit.edu;
> >> >> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> >> >> chur@samsung.com; cm224@samsung.com;
> >> >> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> >> >>
> >> >> 2012/10/8, Jaegeuk Kim :
> >> >> >> -Original Message-
> >> >> >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> >> >> >> Sent: Sunday, October 07, 2012 9:09 PM
> >> >> >> To: Jaegeuk Kim
> >> >> >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
> >> >> >> gre...@linuxfoundation.org; linux-
> >> >> >> ker...@vger.kernel.org; chur@samsung.com;
> >> >> >> cm224@samsung.com;
> >> >> >> jooyoung.hw...@samsung.com;
> >> >> >> linux-fsde...@vger.kernel.org
> >> >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file
> >> >> >> system
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
> >> >> >>
> >> >> >> >> -Original Message-
> >> >> >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> >> >> >> >> Sent: Sunday, October 07, 2012 4:10 PM
> >> >> >> >> To: Jaegeuk Kim
> >> >> >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
> >> >> >> >> ty...@mit.edu; gre...@linuxfoundation.org;
> >> >> >> >> linux-kernel@vger.kernel.org; chur@samsung.com;
> >> >> >> >> cm224@samsung.com;
> >> >> >> jooyoung.hw...@samsung.com;
> >> >> >> >> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
> >> >> >> >>>> Hi Jaegeuk,
> >> >> >> >>>
> >> >> >> >>> Hi.
> >> >> >> >>> We know each other, right? :)
> >> >> >> >>>
> >> >> >> >>>>
> >> >> >> >>>>> From:  김재극 
> >> >> >> >>>>> To:v...@zeniv.linux.org.uk, 'Theodore Ts'o'
> >> >> >> >>>>> ,
> >> >> >> >> gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
> >> >> >> >> chur@samsung.com,
> >> >> >> cm224@samsung.com,
> >> >> >> >> jaegeuk@samsung.com, jooyoung.hw...@samsung.com
> >> >> >

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

> -Original Message-
> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> Sent: Tuesday, October 09, 2012 4:23 AM
> To: Jaegeuk Kim
> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
> gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
> jooyoung.hw...@samsung.com;
> linux-fsde...@vger.kernel.org
> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> 
> Hi,
> 
> On Oct 8, 2012, at 12:25 PM, Jaegeuk Kim wrote:
> 
> >> -Original Message-
> >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> >> Sent: Sunday, October 07, 2012 9:09 PM
> >> To: Jaegeuk Kim
> >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
> >> gre...@linuxfoundation.org; linux-
> >> ker...@vger.kernel.org; chur@samsung.com; cm224....@samsung.com; 
> >> jooyoung.hw...@samsung.com;
> >> linux-fsde...@vger.kernel.org
> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> >>
> >> Hi,
> >>
> >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
> >>
> >>>> -Original Message-
> >>>> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> >>>> Sent: Sunday, October 07, 2012 4:10 PM
> >>>> To: Jaegeuk Kim
> >>>> Cc: Vyacheslav Dubeyko; jaegeuk....@samsung.com; Al Viro; ty...@mit.edu;
> gre...@linuxfoundation.org;
> >>>> linux-kernel@vger.kernel.org; chur@samsung.com; 
> >>>> cm224@samsung.com;
> >> jooyoung.hw...@samsung.com;
> >>>> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
> >>>>>> Hi Jaegeuk,
> >>>>>
> >>>>> Hi.
> >>>>> We know each other, right? :)
> >>>>>
> >>>>>>
> >>>>>>> From: 김재극 
> >>>>>>> To:   v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
> >>>>>>> ,
> >>>> 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 
> >>&g

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

 -Original Message-
 From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
 Sent: Tuesday, October 09, 2012 4:23 AM
 To: Jaegeuk Kim
 Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
 gre...@linuxfoundation.org; linux-
 ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
 jooyoung.hw...@samsung.com;
 linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 Hi,

 On Oct 8, 2012, at 12:25 PM, Jaegeuk Kim wrote:

  -Original Message-
  From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
  Sent: Sunday, October 07, 2012 9:09 PM
  To: Jaegeuk Kim
  Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
  gre...@linuxfoundation.org; linux-
  ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
  jooyoung.hw...@samsung.com;
  linux-fsde...@vger.kernel.org
  Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

  Hi,

  On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

  -Original Message-
  From: Marco Stornelli [mailto:marco.storne...@gmail.com]
  Sent: Sunday, October 07, 2012 4:10 PM
  To: Jaegeuk Kim
  Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu;
 gre...@linuxfoundation.org;
  linux-kernel@vger.kernel.org; chur@samsung.com; 
  cm224@samsung.com;
  jooyoung.hw...@samsung.com;
  linux-fsde...@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 (토), 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.

  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.8812.83 11.43  0.56
  - f2fs:29.7013.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

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system



---
Jaegeuk Kim
Samsung


 -Original Message-
 From: Namjae Jeon [mailto:linkinj...@gmail.com]
 Sent: Tuesday, October 09, 2012 12:52 PM
 To: Jaegeuk Kim
 Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; ty...@mit.edu;
 gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
 chur@samsung.com; cm224@samsung.com;
 jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
 
 2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
  -Original Message-
  From: Namjae Jeon [mailto:linkinj...@gmail.com]
  Sent: Monday, October 08, 2012 8:22 PM
  To: Jaegeuk Kim
  Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
  ty...@mit.edu;
  gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
  chur@samsung.com; cm224@samsung.com;
  jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
  Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
 
  2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
   -Original Message-
   From: Namjae Jeon [mailto:linkinj...@gmail.com]
   Sent: Monday, October 08, 2012 7:00 PM
   To: Jaegeuk Kim
   Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
   ty...@mit.edu;
   gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
   chur@samsung.com; cm224@samsung.com;
   jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
   Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
  
   2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
-Original Message-
From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
Sent: Sunday, October 07, 2012 9:09 PM
To: Jaegeuk Kim
Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
gre...@linuxfoundation.org; linux-
ker...@vger.kernel.org; chur@samsung.com;
cm224@samsung.com;
jooyoung.hw...@samsung.com;
linux-fsde...@vger.kernel.org
Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file
system
   
Hi,
   
On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
   
 -Original Message-
 From: Marco Stornelli [mailto:marco.storne...@gmail.com]
 Sent: Sunday, October 07, 2012 4:10 PM
 To: Jaegeuk Kim
 Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
 ty...@mit.edu; gre...@linuxfoundation.org;
 linux-kernel@vger.kernel.org; chur@samsung.com;
 cm224@samsung.com;
jooyoung.hw...@samsung.com;
 linux-fsde...@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 (토), 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

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Mon, 8 Oct 2012, Jaegeuk Kim wrote:

 Date: Mon, 08 Oct 2012 19:52:03 +0900
 From: Jaegeuk Kim jaegeuk@samsung.com
 To: 'Namjae Jeon' linkinj...@gmail.com
 Cc: 'Vyacheslav Dubeyko' sl...@dubeyko.com,
 'Marco Stornelli' marco.storne...@gmail.com,
 'Jaegeuk Kim' jaegeuk@gmail.com,
 'Al Viro' v...@zeniv.linux.org.uk, ty...@mit.edu,
 gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
 chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com,
 linux-fsde...@vger.kernel.org
 Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

  -Original Message-
  From: Namjae Jeon [mailto:linkinj...@gmail.com]
  Sent: Monday, October 08, 2012 7:00 PM
  To: Jaegeuk Kim
  Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; 
  ty...@mit.edu;
  gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
  chur@samsung.com; cm224@samsung.com;
  jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
  Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

  2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
   -Original Message-
   From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
   Sent: Sunday, October 07, 2012 9:09 PM
   To: Jaegeuk Kim
   Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
   gre...@linuxfoundation.org; linux-
   ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
   jooyoung.hw...@samsung.com;
   linux-fsde...@vger.kernel.org
   Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

   Hi,

   On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

-Original Message-
From: Marco Stornelli [mailto:marco.storne...@gmail.com]
Sent: Sunday, October 07, 2012 4:10 PM
To: Jaegeuk Kim
Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
ty...@mit.edu; gre...@linuxfoundation.org;
linux-kernel@vger.kernel.org; chur@samsung.com;
cm224@samsung.com;
   jooyoung.hw...@samsung.com;
linux-fsde...@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 (토), 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.

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

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

 -Original Message-
 From: linux-fsdevel-ow...@vger.kernel.org 
 [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of
 Luka? Czerner
 Sent: Tuesday, October 09, 2012 5:32 PM
 To: Jaegeuk Kim
 Cc: 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 'Jaegeuk Kim'; 
 'Al Viro'; ty...@mit.edu;
 gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
 chur@samsung.com; cm224@samsung.com;
 jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
 Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

 On Mon, 8 Oct 2012, Jaegeuk Kim wrote:

  Date: Mon, 08 Oct 2012 19:52:03 +0900
  From: Jaegeuk Kim jaegeuk@samsung.com
  To: 'Namjae Jeon' linkinj...@gmail.com
  Cc: 'Vyacheslav Dubeyko' sl...@dubeyko.com,
  'Marco Stornelli' marco.storne...@gmail.com,
  'Jaegeuk Kim' jaegeuk@gmail.com,
  'Al Viro' v...@zeniv.linux.org.uk, ty...@mit.edu,
  gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
  chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com,
  linux-fsde...@vger.kernel.org
  Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

   -Original Message-
   From: Namjae Jeon [mailto:linkinj...@gmail.com]
   Sent: Monday, October 08, 2012 7:00 PM
   To: Jaegeuk Kim
   Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; 
   ty...@mit.edu;
   gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
   chur@samsung.com;
 cm224@samsung.com;
   jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
   Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

   2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
-Original Message-
From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
Sent: Sunday, October 07, 2012 9:09 PM
To: Jaegeuk Kim
Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
gre...@linuxfoundation.org; linux-
ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
jooyoung.hw...@samsung.com;
linux-fsde...@vger.kernel.org
Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

Hi,

On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

 -Original Message-
 From: Marco Stornelli [mailto:marco.storne...@gmail.com]
 Sent: Sunday, October 07, 2012 4:10 PM
 To: Jaegeuk Kim
 Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
 ty...@mit.edu; gre...@linuxfoundation.org;
 linux-kernel@vger.kernel.org; chur@samsung.com;
 cm224@samsung.com;
jooyoung.hw...@samsung.com;
 linux-fsde...@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 (토), 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

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

On Tue, 9 Oct 2012, Jaegeuk Kim wrote:

 Date: Tue, 09 Oct 2012 19:45:57 +0900
 From: Jaegeuk Kim jaegeuk@samsung.com
 To: 'Lukáš Czerner' lczer...@redhat.com
 Cc: 'Namjae Jeon' linkinj...@gmail.com,
 'Vyacheslav Dubeyko' sl...@dubeyko.com,
 'Marco Stornelli' marco.storne...@gmail.com,
 'Jaegeuk Kim' jaegeuk@gmail.com,
 'Al Viro' v...@zeniv.linux.org.uk, ty...@mit.edu,
 gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
 chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com,
 linux-fsde...@vger.kernel.org
 Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
 
  -Original Message-
  From: linux-fsdevel-ow...@vger.kernel.org 
  [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of
  Luka? Czerner
  Sent: Tuesday, October 09, 2012 5:32 PM
  To: Jaegeuk Kim
  Cc: 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 'Jaegeuk Kim'; 
  'Al Viro'; ty...@mit.edu;
  gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
  chur@samsung.com; cm224@samsung.com;
  jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
  Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
  
  On Mon, 8 Oct 2012, Jaegeuk Kim wrote:
  
   Date: Mon, 08 Oct 2012 19:52:03 +0900
   From: Jaegeuk Kim jaegeuk@samsung.com
   To: 'Namjae Jeon' linkinj...@gmail.com
   Cc: 'Vyacheslav Dubeyko' sl...@dubeyko.com,
   'Marco Stornelli' marco.storne...@gmail.com,
   'Jaegeuk Kim' jaegeuk@gmail.com,
   'Al Viro' v...@zeniv.linux.org.uk, ty...@mit.edu,
   gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
   chur@samsung.com, cm224@samsung.com, 
   jooyoung.hw...@samsung.com,
   linux-fsde...@vger.kernel.org
   Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
  
-Original Message-
From: Namjae Jeon [mailto:linkinj...@gmail.com]
Sent: Monday, October 08, 2012 7:00 PM
To: Jaegeuk Kim
Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; 
ty...@mit.edu;
gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
chur@samsung.com;
  cm224@samsung.com;
jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
   
2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
 -Original Message-
 From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
 Sent: Sunday, October 07, 2012 9:09 PM
 To: Jaegeuk Kim
 Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
 gre...@linuxfoundation.org; linux-
 ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
 jooyoung.hw...@samsung.com;
 linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 Hi,

 On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

  -Original Message-
  From: Marco Stornelli [mailto:marco.storne...@gmail.com]
  Sent: Sunday, October 07, 2012 4:10 PM
  To: Jaegeuk Kim
  Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
  ty...@mit.edu; gre...@linuxfoundation.org;
  linux-kernel@vger.kernel.org; chur@samsung.com;
  cm224@samsung.com;
 jooyoung.hw...@samsung.com;
  linux-fsde...@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 (토), 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

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

 -Original Message-
 From: Lukáš Czerner [mailto:lczer...@redhat.com]
 Sent: Tuesday, October 09, 2012 8:01 PM
 To: Jaegeuk Kim
 Cc: 'Lukáš Czerner'; 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 
 'Jaegeuk Kim'; 'Al Viro';
 ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
 chur@samsung.com;
 cm224@samsung.com; jooyoung.hw...@samsung.com; 
 linux-fsde...@vger.kernel.org
 Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
 
 On Tue, 9 Oct 2012, Jaegeuk Kim wrote:
 
  Date: Tue, 09 Oct 2012 19:45:57 +0900
  From: Jaegeuk Kim jaegeuk@samsung.com
  To: 'Lukáš Czerner' lczer...@redhat.com
  Cc: 'Namjae Jeon' linkinj...@gmail.com,
  'Vyacheslav Dubeyko' sl...@dubeyko.com,
  'Marco Stornelli' marco.storne...@gmail.com,
  'Jaegeuk Kim' jaegeuk@gmail.com,
  'Al Viro' v...@zeniv.linux.org.uk, ty...@mit.edu,
  gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
  chur@samsung.com, cm224@samsung.com, jooyoung.hw...@samsung.com,
  linux-fsde...@vger.kernel.org
  Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
 
   -Original Message-
   From: linux-fsdevel-ow...@vger.kernel.org 
   [mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf
 Of
   Luka? Czerner
   Sent: Tuesday, October 09, 2012 5:32 PM
   To: Jaegeuk Kim
   Cc: 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli'; 'Jaegeuk 
   Kim'; 'Al Viro';
 ty...@mit.edu;
   gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
   chur@samsung.com;
 cm224@samsung.com;
   jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
   Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
  
   On Mon, 8 Oct 2012, Jaegeuk Kim wrote:
  
Date: Mon, 08 Oct 2012 19:52:03 +0900
From: Jaegeuk Kim jaegeuk@samsung.com
To: 'Namjae Jeon' linkinj...@gmail.com
Cc: 'Vyacheslav Dubeyko' sl...@dubeyko.com,
'Marco Stornelli' marco.storne...@gmail.com,
'Jaegeuk Kim' jaegeuk@gmail.com,
'Al Viro' v...@zeniv.linux.org.uk, ty...@mit.edu,
gre...@linuxfoundation.org, linux-kernel@vger.kernel.org,
chur@samsung.com, cm224@samsung.com, 
jooyoung.hw...@samsung.com,
linux-fsde...@vger.kernel.org
Subject: RE: [PATCH 00/16] f2fs: introduce flash-friendly file system
   
 -Original Message-
 From: Namjae Jeon [mailto:linkinj...@gmail.com]
 Sent: Monday, October 08, 2012 7:00 PM
 To: Jaegeuk Kim
 Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; 
 ty...@mit.edu;
 gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
 chur@samsung.com;
   cm224@samsung.com;
 jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
  -Original Message-
  From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
  Sent: Sunday, October 07, 2012 9:09 PM
  To: Jaegeuk Kim
  Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
  gre...@linuxfoundation.org; linux-
  ker...@vger.kernel.org; chur@samsung.com; 
  cm224@samsung.com;
  jooyoung.hw...@samsung.com;
  linux-fsde...@vger.kernel.org
  Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file 
  system
 
  Hi,
 
  On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
 
   -Original Message-
   From: Marco Stornelli [mailto:marco.storne...@gmail.com]
   Sent: Sunday, October 07, 2012 4:10 PM
   To: Jaegeuk Kim
   Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
   ty...@mit.edu; gre...@linuxfoundation.org;
   linux-kernel@vger.kernel.org; chur@samsung.com;
   cm224@samsung.com;
  jooyoung.hw...@samsung.com;
   linux-fsde...@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 (토), 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

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

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

-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
--
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/

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

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-09 Thread Jooyoung Hwang

On Tue, 2012-10-09 at 16:08 +0900, Jaegeuk Kim wrote:
  -Original Message-
  From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
  Sent: Tuesday, October 09, 2012 4:23 AM
  To: Jaegeuk Kim
  Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
  gre...@linuxfoundation.org; linux-
  ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
  jooyoung.hw...@samsung.com;
  linux-fsde...@vger.kernel.org
  Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

  Hi,

  On Oct 8, 2012, at 12:25 PM, Jaegeuk Kim wrote:

   -Original Message-
   From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
   Sent: Sunday, October 07, 2012 9:09 PM
   To: Jaegeuk Kim
   Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
   gre...@linuxfoundation.org; linux-
   ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
   jooyoung.hw...@samsung.com;
   linux-fsde...@vger.kernel.org
   Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

   Hi,

   On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

   -Original Message-
   From: Marco Stornelli [mailto:marco.storne...@gmail.com]
   Sent: Sunday, October 07, 2012 4:10 PM
   To: Jaegeuk Kim
   Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; 
   ty...@mit.edu;
  gre...@linuxfoundation.org;
   linux-kernel@vger.kernel.org; chur@samsung.com; 
   cm224@samsung.com;
   jooyoung.hw...@samsung.com;
   linux-fsde...@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 (토), 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.

   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.8812.83

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-09 Thread Dave Chinner

[ Folks, can you trim your responses down to just quote the part you
are responding to? Having to repeatedly scroll through 500 lines of
irrelevant text just to find the 5 lines that is being commented on
is exceedingly painful. ]

On Tue, Oct 09, 2012 at 09:01:18PM +0900, Jaegeuk Kim wrote:
From: Lukáš Czerner [mailto:lczer...@redhat.com]
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.

And in response, other people are suggesting that this is the
wrong approach.

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.

Linaro already have one, which is another reason why using
heuristics is the wrong approach:

https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey?action=showredirect=WorkingGroups%2FKernelConsolidation%2FProjects%2FFlashCardSurvey

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?

It's public information.

If you want to support different types of flash, then either add
your timing attack derived information on specific hardware to the
above table, or force vendors to update it themselves if they want
their flash memory supported by this filesystem.

Cheers,

Dave.
--
Dave Chinner
da...@fromorbit.com
--
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/

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

-Original Message-
From: linux-fsdevel-ow...@vger.kernel.org
[mailto:linux-fsdevel-ow...@vger.kernel.org] On Behalf Of
Dave Chinner
Sent: Wednesday, October 10, 2012 6:20 AM
To: Jaegeuk Kim
Cc: 'Lukáš Czerner'; 'Namjae Jeon'; 'Vyacheslav Dubeyko'; 'Marco Stornelli';
'Jaegeuk Kim'; 'Al Viro';
ty...@mit.edu; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
chur@samsung.com;
cm224@samsung.com; jooyoung.hw...@samsung.com;
linux-fsde...@vger.kernel.org
Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

Ok, I'll keep in mind.
Thanks.

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.

And in response, other people are suggesting that this is the
wrong approach.

Ok, it makes sense.
I agree that the Linaro survey has been well proceeded, and no more heuristic
is needed.

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.

Linaro already have one, which is another reason why using
heuristics is the wrong approach:

https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey?action=showredirect=WorkingGrou
ps%2FKernelConsolidation%2FProjects%2FFlashCardSurvey

Anyway, it's very interesting to build a database gathering products'
information.
May I access the database?

It's public information.

Sound good.
If I also get something, I'll try.
Thank you.

Cheers,

Dave.
--
Dave Chinner
da...@fromorbit.com
--
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012/10/8, Jaegeuk Kim :
>> -Original Message-
>> From: Namjae Jeon [mailto:linkinj...@gmail.com]
>> Sent: Monday, October 08, 2012 8:22 PM
>> To: Jaegeuk Kim
>> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
>> ty...@mit.edu;
>> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
>> chur@samsung.com; cm224@samsung.com;
>> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
>> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
>>
>> 2012/10/8, Jaegeuk Kim :
>> >> -Original Message-
>> >> From: Namjae Jeon [mailto:linkinj...@gmail.com]
>> >> Sent: Monday, October 08, 2012 7:00 PM
>> >> To: Jaegeuk Kim
>> >> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
>> >> ty...@mit.edu;
>> >> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
>> >> chur....@samsung.com; cm224@samsung.com;
>> >> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
>> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
>> >>
>> >> 2012/10/8, Jaegeuk Kim :
>> >> >> -Original Message-
>> >> >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
>> >> >> Sent: Sunday, October 07, 2012 9:09 PM
>> >> >> To: Jaegeuk Kim
>> >> >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
>> >> >> gre...@linuxfoundation.org; linux-
>> >> >> ker...@vger.kernel.org; chur@samsung.com;
>> >> >> cm224@samsung.com;
>> >> >> jooyoung.hw...@samsung.com;
>> >> >> linux-fsde...@vger.kernel.org
>> >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file
>> >> >> system
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
>> >> >>
>> >> >> >> -----Original Message-
>> >> >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
>> >> >> >> Sent: Sunday, October 07, 2012 4:10 PM
>> >> >> >> To: Jaegeuk Kim
>> >> >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
>> >> >> >> ty...@mit.edu; gre...@linuxfoundation.org;
>> >> >> >> linux-kernel@vger.kernel.org; chur@samsung.com;
>> >> >> >> cm224@samsung.com;
>> >> >> jooyoung.hw...@samsung.com;
>> >> >> >> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
>> >> >> >>>> Hi Jaegeuk,
>> >> >> >>>
>> >> >> >>> Hi.
>> >> >> >>> We know each other, right? :)
>> >> >> >>>
>> >> >> >>>>
>> >> >> >>>>> From:김재극 
>> >> >> >>>>> To:  v...@zeniv.linux.org.uk, 'Theodore Ts'o'
>> >> >> >>>>> ,
>> >> >> >> 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
>> >> >> &

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-08 Thread Vyacheslav Dubeyko

Hi,

On Oct 8, 2012, at 12:25 PM, Jaegeuk Kim wrote:

>> -Original Message-
>> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
>> Sent: Sunday, October 07, 2012 9:09 PM
>> To: Jaegeuk Kim
>> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
>> gre...@linuxfoundation.org; linux-
>> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
>> jooyoung.hw...@samsung.com;
>> linux-fsde...@vger.kernel.org
>> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
>> 
>> Hi,
>> 
>> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
>> 
>>>> -Original Message-
>>>> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
>>>> Sent: Sunday, October 07, 2012 4:10 PM
>>>> To: Jaegeuk Kim
>>>> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu; 
>>>> gre...@linuxfoundation.org;
>>>> linux-kernel@vger.kernel.org; chur....@samsung.com; cm224@samsung.com;
>> jooyoung.hw...@samsung.com;
>>>> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
>>>>>> Hi Jaegeuk,
>>>>> 
>>>>> Hi.
>>>>> We know each other, right? :)
>>>>> 
>>>>>> 
>>>>>>> From:   김재극 
>>>>>>> To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
>>>>>>> ,
>>>> 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 wou

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

> -Original Message-
> From: Namjae Jeon [mailto:linkinj...@gmail.com]
> Sent: Monday, October 08, 2012 8:22 PM
> To: Jaegeuk Kim
> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; ty...@mit.edu;
> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> chur@samsung.com; cm224@samsung.com;
> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> 
> 2012/10/8, Jaegeuk Kim :
> >> -Original Message-
> >> From: Namjae Jeon [mailto:linkinj...@gmail.com]
> >> Sent: Monday, October 08, 2012 7:00 PM
> >> To: Jaegeuk Kim
> >> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
> >> ty...@mit.edu;
> >> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
> >> chur@samsung.com; cm224....@samsung.com;
> >> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> >>
> >> 2012/10/8, Jaegeuk Kim :
> >> >> -Original Message-
> >> >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> >> >> Sent: Sunday, October 07, 2012 9:09 PM
> >> >> To: Jaegeuk Kim
> >> >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
> >> >> gre...@linuxfoundation.org; linux-
> >> >> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
> >> >> jooyoung.hw...@samsung.com;
> >> >> linux-fsde...@vger.kernel.org
> >> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> >> >>
> >> >> Hi,
> >> >>
> >> >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
> >> >>
> >> >> >> -Original Message-
> >> >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> >> >> >> Sent: Sunday, October 07, 2012 4:10 PM
> >> >> >> To: Jaegeuk Kim
> >> >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
> >> >> >> ty...@mit.edu; gre...@linuxfoundation.org;
> >> >> >> linux-kernel@vger.kernel.org; chur@samsung.com;
> >> >> >> cm224@samsung.com;
> >> >> jooyoung.hw...@samsung.com;
> >> >> >> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
> >> >> >>>> Hi Jaegeuk,
> >> >> >>>
> >> >> >>> Hi.
> >> >> >>> We know each other, right? :)
> >> >> >>>
> >> >> >>>>
> >> >> >>>>> From: 김재극 
> >> >> >>>>> To:   v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
> >> >> >>>>> ,
> >> >> >> 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,
> >

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012/10/8, Jaegeuk Kim :
>> -Original Message-
>> From: Namjae Jeon [mailto:linkinj...@gmail.com]
>> Sent: Monday, October 08, 2012 7:00 PM
>> To: Jaegeuk Kim
>> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
>> ty...@mit.edu;
>> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
>> chur@samsung.com; cm224@samsung.com;
>> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
>> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
>>
>> 2012/10/8, Jaegeuk Kim :
>> >> -Original Message-
>> >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
>> >> Sent: Sunday, October 07, 2012 9:09 PM
>> >> To: Jaegeuk Kim
>> >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
>> >> gre...@linuxfoundation.org; linux-
>> >> ker...@vger.kernel.org; chur....@samsung.com; cm224....@samsung.com;
>> >> jooyoung.hw...@samsung.com;
>> >> linux-fsde...@vger.kernel.org
>> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
>> >>
>> >> Hi,
>> >>
>> >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
>> >>
>> >> >> -Original Message-
>> >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
>> >> >> Sent: Sunday, October 07, 2012 4:10 PM
>> >> >> To: Jaegeuk Kim
>> >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
>> >> >> ty...@mit.edu; gre...@linuxfoundation.org;
>> >> >> linux-kernel@vger.kernel.org; chur@samsung.com;
>> >> >> cm224@samsung.com;
>> >> jooyoung.hw...@samsung.com;
>> >> >> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
>> >> >>>> Hi Jaegeuk,
>> >> >>>
>> >> >>> Hi.
>> >> >>> We know each other, right? :)
>> >> >>>
>> >> >>>>
>> >> >>>>> From:   김재극 
>> >> >>>>> To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
>> >> >>>>> ,
>> >> >> 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
>> >>

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

> -Original Message-
> From: Namjae Jeon [mailto:linkinj...@gmail.com]
> Sent: Monday, October 08, 2012 7:00 PM
> To: Jaegeuk Kim
> Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; ty...@mit.edu;
> gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> chur@samsung.com; cm224@samsung.com;
> jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> 
> 2012/10/8, Jaegeuk Kim :
> >> -Original Message-
> >> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> >> Sent: Sunday, October 07, 2012 9:09 PM
> >> To: Jaegeuk Kim
> >> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
> >> gre...@linuxfoundation.org; linux-
> >> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
> >> jooyoung.hw...@samsung.com;
> >> linux-fsde...@vger.kernel.org
> >> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> >>
> >> Hi,
> >>
> >> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
> >>
> >> >> -Original Message-
> >> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> >> >> Sent: Sunday, October 07, 2012 4:10 PM
> >> >> To: Jaegeuk Kim
> >> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
> >> >> ty...@mit.edu; gre...@linuxfoundation.org;
> >> >> linux-kernel@vger.kernel.org; chur@samsung.com;
> >> >> cm224@samsung.com;
> >> jooyoung.hw...@samsung.com;
> >> >> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
> >> >>>> Hi Jaegeuk,
> >> >>>
> >> >>> Hi.
> >> >>> We know each other, right? :)
> >> >>>
> >> >>>>
> >> >>>>> From:김재극 
> >> >>>>> To:  v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
> >> >>>>> ,
> >> >> 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

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012/10/8, Jaegeuk Kim :
>> -Original Message-
>> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
>> Sent: Sunday, October 07, 2012 9:09 PM
>> To: Jaegeuk Kim
>> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
>> gre...@linuxfoundation.org; linux-
>> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
>> jooyoung.hw...@samsung.com;
>> linux-fsde...@vger.kernel.org
>> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
>>
>> Hi,
>>
>> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
>>
>> >> -Original Message-
>> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
>> >> Sent: Sunday, October 07, 2012 4:10 PM
>> >> To: Jaegeuk Kim
>> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
>> >> ty...@mit.edu; gre...@linuxfoundation.org;
>> >> linux-kernel@vger.kernel.org; chur....@samsung.com;
>> >> cm224@samsung.com;
>> jooyoung.hw...@samsung.com;
>> >> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
>> >>>> Hi Jaegeuk,
>> >>>
>> >>> Hi.
>> >>> We know each other, right? :)
>> >>>
>> >>>>
>> >>>>> From:  김재극 
>> >>>>> To:v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
>> >>>>> ,
>> >> 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
>> >>&

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

> -Original Message-
> From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
> Sent: Sunday, October 07, 2012 9:09 PM
> To: Jaegeuk Kim
> Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
> gre...@linuxfoundation.org; linux-
> ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
> jooyoung.hw...@samsung.com;
> linux-fsde...@vger.kernel.org
> Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system
> 
> Hi,
> 
> On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:
> 
> >> -Original Message-
> >> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> >> Sent: Sunday, October 07, 2012 4:10 PM
> >> To: Jaegeuk Kim
> >> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu; 
> >> gre...@linuxfoundation.org;
> >> linux-kernel@vger.kernel.org; chur@samsung.com; cm224....@samsung.com;
> jooyoung.hw...@samsung.com;
> >> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
> >>>> Hi Jaegeuk,
> >>>
> >>> Hi.
> >>> We know each other, right? :)
> >>>
> >>>>
> >>>>> From:   김재극 
> >>>>> To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
> >>>>> ,
> >> 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 co

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

 -Original Message-
 From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
 Sent: Sunday, October 07, 2012 9:09 PM
 To: Jaegeuk Kim
 Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
 gre...@linuxfoundation.org; linux-
 ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
 jooyoung.hw...@samsung.com;
 linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 Hi,

 On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

  -Original Message-
  From: Marco Stornelli [mailto:marco.storne...@gmail.com]
  Sent: Sunday, October 07, 2012 4:10 PM
  To: Jaegeuk Kim
  Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu; 
  gre...@linuxfoundation.org;
  linux-kernel@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
 jooyoung.hw...@samsung.com;
  linux-fsde...@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 (토), 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.

  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.8812.83 11.43  0.56
  - f2fs:29.7013.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-fsdevel.

  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? Or 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 systems.
  Here

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
 -Original Message-
 From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
 Sent: Sunday, October 07, 2012 9:09 PM
 To: Jaegeuk Kim
 Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
 gre...@linuxfoundation.org; linux-
 ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
 jooyoung.hw...@samsung.com;
 linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 Hi,

 On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

  -Original Message-
  From: Marco Stornelli [mailto:marco.storne...@gmail.com]
  Sent: Sunday, October 07, 2012 4:10 PM
  To: Jaegeuk Kim
  Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
  ty...@mit.edu; gre...@linuxfoundation.org;
  linux-kernel@vger.kernel.org; chur@samsung.com;
  cm224@samsung.com;
 jooyoung.hw...@samsung.com;
  linux-fsde...@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 (토), 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.

  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.8812.83 11.43  0.56
  - f2fs:29.7013.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-fsdevel.

  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? Or 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

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

 -Original Message-
 From: Namjae Jeon [mailto:linkinj...@gmail.com]
 Sent: Monday, October 08, 2012 7:00 PM
 To: Jaegeuk Kim
 Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; ty...@mit.edu;
 gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
 chur@samsung.com; cm224@samsung.com;
 jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
  -Original Message-
  From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
  Sent: Sunday, October 07, 2012 9:09 PM
  To: Jaegeuk Kim
  Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
  gre...@linuxfoundation.org; linux-
  ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
  jooyoung.hw...@samsung.com;
  linux-fsde...@vger.kernel.org
  Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

  Hi,

  On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

   -Original Message-
   From: Marco Stornelli [mailto:marco.storne...@gmail.com]
   Sent: Sunday, October 07, 2012 4:10 PM
   To: Jaegeuk Kim
   Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
   ty...@mit.edu; gre...@linuxfoundation.org;
   linux-kernel@vger.kernel.org; chur@samsung.com;
   cm224@samsung.com;
  jooyoung.hw...@samsung.com;
   linux-fsde...@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 (토), 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.

   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.8812.83 11.43  0.56
   - f2fs:29.7013.34 10.79 12.82

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
 -Original Message-
 From: Namjae Jeon [mailto:linkinj...@gmail.com]
 Sent: Monday, October 08, 2012 7:00 PM
 To: Jaegeuk Kim
 Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
 ty...@mit.edu;
 gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
 chur@samsung.com; cm224@samsung.com;
 jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
  -Original Message-
  From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
  Sent: Sunday, October 07, 2012 9:09 PM
  To: Jaegeuk Kim
  Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
  gre...@linuxfoundation.org; linux-
  ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
  jooyoung.hw...@samsung.com;
  linux-fsde...@vger.kernel.org
  Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

  Hi,

  On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

   -Original Message-
   From: Marco Stornelli [mailto:marco.storne...@gmail.com]
   Sent: Sunday, October 07, 2012 4:10 PM
   To: Jaegeuk Kim
   Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
   ty...@mit.edu; gre...@linuxfoundation.org;
   linux-kernel@vger.kernel.org; chur@samsung.com;
   cm224@samsung.com;
  jooyoung.hw...@samsung.com;
   linux-fsde...@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 (토), 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.

   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.8812.83 11.43

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

 -Original Message-
 From: Namjae Jeon [mailto:linkinj...@gmail.com]
 Sent: Monday, October 08, 2012 8:22 PM
 To: Jaegeuk Kim
 Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro; ty...@mit.edu;
 gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
 chur@samsung.com; cm224@samsung.com;
 jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
  -Original Message-
  From: Namjae Jeon [mailto:linkinj...@gmail.com]
  Sent: Monday, October 08, 2012 7:00 PM
  To: Jaegeuk Kim
  Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
  ty...@mit.edu;
  gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
  chur@samsung.com; cm224@samsung.com;
  jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
  Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

  2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
   -Original Message-
   From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
   Sent: Sunday, October 07, 2012 9:09 PM
   To: Jaegeuk Kim
   Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
   gre...@linuxfoundation.org; linux-
   ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
   jooyoung.hw...@samsung.com;
   linux-fsde...@vger.kernel.org
   Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

   Hi,

   On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

-Original Message-
From: Marco Stornelli [mailto:marco.storne...@gmail.com]
Sent: Sunday, October 07, 2012 4:10 PM
To: Jaegeuk Kim
Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
ty...@mit.edu; gre...@linuxfoundation.org;
linux-kernel@vger.kernel.org; chur@samsung.com;
cm224@samsung.com;
   jooyoung.hw...@samsung.com;
linux-fsde...@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 (토), 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.

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

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-08 Thread Vyacheslav Dubeyko

Hi,

On Oct 8, 2012, at 12:25 PM, Jaegeuk Kim wrote:

 -Original Message-
 From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
 Sent: Sunday, October 07, 2012 9:09 PM
 To: Jaegeuk Kim
 Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu; 
 gre...@linuxfoundation.org; linux-
 ker...@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
 jooyoung.hw...@samsung.com;
 linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 Hi,

 On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

 -Original Message-
 From: Marco Stornelli [mailto:marco.storne...@gmail.com]
 Sent: Sunday, October 07, 2012 4:10 PM
 To: Jaegeuk Kim
 Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu; 
 gre...@linuxfoundation.org;
 linux-kernel@vger.kernel.org; chur@samsung.com; cm224@samsung.com;
 jooyoung.hw...@samsung.com;
 linux-fsde...@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 (토), 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.

 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.8812.83 11.43  0.56
 - f2fs:29.7013.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-fsdevel.

 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? Or 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 systems.
 Here are several log-structured file systems

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
 -Original Message-
 From: Namjae Jeon [mailto:linkinj...@gmail.com]
 Sent: Monday, October 08, 2012 8:22 PM
 To: Jaegeuk Kim
 Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
 ty...@mit.edu;
 gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
 chur@samsung.com; cm224@samsung.com;
 jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
 Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

 2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
  -Original Message-
  From: Namjae Jeon [mailto:linkinj...@gmail.com]
  Sent: Monday, October 08, 2012 7:00 PM
  To: Jaegeuk Kim
  Cc: Vyacheslav Dubeyko; Marco Stornelli; Jaegeuk Kim; Al Viro;
  ty...@mit.edu;
  gre...@linuxfoundation.org; linux-kernel@vger.kernel.org;
  chur@samsung.com; cm224@samsung.com;
  jooyoung.hw...@samsung.com; linux-fsde...@vger.kernel.org
  Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

  2012/10/8, Jaegeuk Kim jaegeuk@samsung.com:
   -Original Message-
   From: Vyacheslav Dubeyko [mailto:sl...@dubeyko.com]
   Sent: Sunday, October 07, 2012 9:09 PM
   To: Jaegeuk Kim
   Cc: 'Marco Stornelli'; 'Jaegeuk Kim'; 'Al Viro'; ty...@mit.edu;
   gre...@linuxfoundation.org; linux-
   ker...@vger.kernel.org; chur@samsung.com;
   cm224@samsung.com;
   jooyoung.hw...@samsung.com;
   linux-fsde...@vger.kernel.org
   Subject: Re: [PATCH 00/16] f2fs: introduce flash-friendly file
   system

   Hi,

   On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

-Original Message-
From: Marco Stornelli [mailto:marco.storne...@gmail.com]
Sent: Sunday, October 07, 2012 4:10 PM
To: Jaegeuk Kim
Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro;
ty...@mit.edu; gre...@linuxfoundation.org;
linux-kernel@vger.kernel.org; chur@samsung.com;
cm224@samsung.com;
   jooyoung.hw...@samsung.com;
linux-fsde...@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 (토), 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.

It's definitely right, and I meant *for a while*.
I just wanted to avoid arguing with how

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

Hi,

On Oct 7, 2012, at 1:31 PM, Jaegeuk Kim wrote:

>> -Original Message-
>> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
>> Sent: Sunday, October 07, 2012 4:10 PM
>> To: Jaegeuk Kim
>> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu; 
>> gre...@linuxfoundation.org;
>> linux-kernel@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
>> jooyoung.hw...@samsung.com;
>> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
>>>> Hi Jaegeuk,
>>> 
>>> Hi.
>>> We know each other, right? :)
>>> 
>>>> 
>>>>> From: 김재극 
>>>>> To:   v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
>>>>> ,
>> 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".
> 
> 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. writ

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system


Hi,

On Oct 7, 2012, at 12:06 AM, Jaegeuk Kim wrote:

> 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko:
>> Hi Jaegeuk,
> 
> Hi.
> We know each other, right? :)
> 

Yes, you are correct. :-)

>> 
>>> From:   김재극 
>>> To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' , 
>>> 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,

It is a good strategy. But it exists known bottlenecks and, maybe, it makes 
sense to begin discussion in the community.

With the best regards,
Vyacheslav Dubeyko.

> 
>> With the best regards,
>> Vyacheslav Dubeyko.
>> 
>>> Patch set
>>> =
>>> 
>>> The patch #1 adds a document to Documentation/filesystems/.
>>> The patch #2 adds a header file of on-disk layout to include/linux/.
>>> The patches #3-#15 adds f2fs source files to fs/f2fs/.
>>> The Last patch, patch #16, updates Makefile and Kconfig.
>>> 
>>> mkfs.f2fs
>>> =
>>> 
>>> The file system formatting tool, "mkfs.f2fs", is available from the 
>>> following
>>> download page:  
>>> http://sourceforge.net/projects/f2fs-tools/
>>> 
>>> 
>>> Usage
>>> =
>>> 
>>> If you'd like to experience f2fs, simply:
>>> # mkfs.f2fs /dev/sdb1
>>> # mount -t f2fs /dev/sdb1 /mnt/f2fs
>>> 
>>> Short log
>>> =
>>> 
>>> Jaegeuk Kim (16):
>>> f2fs: add document
>>> f2fs: add on-disk layout
>>> f2fs: add superblock and major in-memory structure
>>> f2fs: add super block operations
>>> f2fs: add checkpoint operations
>>> f2fs: add node operations
>>> f2fs: add segment operations
>>> f2fs: add file operations
>>> f2fs: add address space operations for data
>>> f2fs: add core inode operations
>>> f2fs: add inode operations for special inodes
>>> f2fs: add core directory operations
>>> f2fs: add xattr and acl functionalities
>>> f2fs: add garbage collection functions
>>> f2fs: add recovery routines for roll-forward
>>> f2fs: update Kconfig and Makefile
>>> 
>>> Documentation/filesystems/00-INDEX |2 +
>>> Documentation/filesystems/f2fs.txt |  314 +++
>>> fs/Kconfig |1 +
>>> fs/Makefile|1 +
>>> fs/f2fs/Kconfig|   55 ++
>>> fs/f2fs/Makefile   |6 +
>>> fs/f2fs/acl.c  |  402 
>>> fs/f2fs/acl.h  |   57 ++
>>> fs/f2fs/checkpoint.c   |  791 
>>> fs/f2fs/data.c |  700 ++
>>> fs/f2fs/dir.c  |  657 +
>>> fs/f2fs/f2fs.h |  981 
>>> fs/f2fs/file.c |  643 +
>>> fs/f2fs/gc.c   | 1140 +++
>>> fs/f2fs/gc.h   |  203 +
>>> fs/f2fs/hash.c |   98 ++
>>> fs/f2fs/inode.c|  258 ++
>>> fs/f2fs/namei.c|  549 +++
>>> fs/f2fs/node.c | 1773 
>>> 
>>> fs/f2fs/node.h

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-07 Thread Jaegeuk Kim

> -Original Message-
> From: Marco Stornelli [mailto:marco.storne...@gmail.com]
> Sent: Sunday, October 07, 2012 4:10 PM
> To: Jaegeuk Kim
> Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu; 
> gre...@linuxfoundation.org;
> linux-kernel@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
> jooyoung.hw...@samsung.com;
> linux-fsde...@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 (토), 17:54 +0400, Vyacheslav Dubeyko:
> >> Hi Jaegeuk,
> >
> > Hi.
> > We know each other, right? :)
> >
> >>
> >>> From: 김재극 
> >>> To:   v...@zeniv.linux.org.uk, 'Theodore Ts'o' 
> >>> ,
> 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".

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.8812.83 11.43  0.56
 - f2fs:29.7013.34 10.79 12.82

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-fsdevel.

Yes, that was totally my mistake.

> 3) It's not clear the pros/cons of your filesystem, can you share with
> us th

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-07 Thread Marco Stornelli


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:   김재극 
To: v...@zeniv.linux.org.uk, 'Theodore Ts'o' , 
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/

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-07 Thread Marco Stornelli


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/

RE: [PATCH 00/16] f2fs: introduce flash-friendly file system

2012-10-07 Thread Jaegeuk Kim

 -Original Message-
 From: Marco Stornelli [mailto:marco.storne...@gmail.com]
 Sent: Sunday, October 07, 2012 4:10 PM
 To: Jaegeuk Kim
 Cc: Vyacheslav Dubeyko; jaegeuk@samsung.com; Al Viro; ty...@mit.edu; 
 gre...@linuxfoundation.org;
 linux-kernel@vger.kernel.org; chur@samsung.com; cm224@samsung.com; 
 jooyoung.hw...@samsung.com;
 linux-fsde...@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 (토), 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.

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.8812.83 11.43  0.56
 - f2fs:29.7013.34 10.79 12.82

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-fsdevel.

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? Or 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 systems.
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 designed 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 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

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system


Hi,

On Oct 7, 2012, at 12:06 AM, Jaegeuk Kim wrote:

 2012-10-06 (토), 17:54 +0400, Vyacheslav Dubeyko:
 Hi Jaegeuk,
 
 Hi.
 We know each other, right? :)
 

Yes, you are correct. :-)

 
 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,

It is a good strategy. But it exists known bottlenecks and, maybe, it makes 
sense to begin discussion in the community.

With the best regards,
Vyacheslav Dubeyko.

 
 With the best regards,
 Vyacheslav Dubeyko.
 
 Patch set
 =
 
 The patch #1 adds a document to Documentation/filesystems/.
 The patch #2 adds a header file of on-disk layout to include/linux/.
 The patches #3-#15 adds f2fs source files to fs/f2fs/.
 The Last patch, patch #16, updates Makefile and Kconfig.
 
 mkfs.f2fs
 =
 
 The file system formatting tool, mkfs.f2fs, is available from the 
 following
 download page:  
 http://sourceforge.net/projects/f2fs-tools/
 
 
 Usage
 =
 
 If you'd like to experience f2fs, simply:
 # mkfs.f2fs /dev/sdb1
 # mount -t f2fs /dev/sdb1 /mnt/f2fs
 
 Short log
 =
 
 Jaegeuk Kim (16):
 f2fs: add document
 f2fs: add on-disk layout
 f2fs: add superblock and major in-memory structure
 f2fs: add super block operations
 f2fs: add checkpoint operations
 f2fs: add node operations
 f2fs: add segment operations
 f2fs: add file operations
 f2fs: add address space operations for data
 f2fs: add core inode operations
 f2fs: add inode operations for special inodes
 f2fs: add core directory operations
 f2fs: add xattr and acl functionalities
 f2fs: add garbage collection functions
 f2fs: add recovery routines for roll-forward
 f2fs: update Kconfig and Makefile
 
 Documentation/filesystems/00-INDEX |2 +
 Documentation/filesystems/f2fs.txt |  314 +++
 fs/Kconfig |1 +
 fs/Makefile|1 +
 fs/f2fs/Kconfig|   55 ++
 fs/f2fs/Makefile   |6 +
 fs/f2fs/acl.c  |  402 
 fs/f2fs/acl.h  |   57 ++
 fs/f2fs/checkpoint.c   |  791 
 fs/f2fs/data.c |  700 ++
 fs/f2fs/dir.c  |  657 +
 fs/f2fs/f2fs.h |  981 
 fs/f2fs/file.c |  643 +
 fs/f2fs/gc.c   | 1140 +++
 fs/f2fs/gc.h   |  203 +
 fs/f2fs/hash.c |   98 ++
 fs/f2fs/inode.c|  258 ++
 fs/f2fs/namei.c|  549 +++
 fs/f2fs/node.c | 1773 
 
 fs/f2fs/node.h |  331 +++
 fs/f2fs/recovery.c |  372 
 fs/f2fs/segment.c  | 1755 
 +++
 fs/f2fs/segment.h  |  627 +
 fs/f2fs/super.c|  550 +++
 fs/f2fs/xattr.c|  387

Re: [PATCH 00/16] f2fs: introduce flash-friendly file system