BTRFS && SSD

BTRFS && SSD

[Yuehai Xu]

Hi,

I know BTRFS is a kind of Log-structured File System, which doesn't do
overwrite. Here is my question, suppose file A is overwritten by A',
instead of writing A' to the original place of A, a new place is
selected to store it. However, we know that the address of a file
should be recorded in its inode. In such case, the corresponding part
in inode of A should update from the original place A to the new place
A', is this a kind of overwrite actually? I think no matter what
design it is for Log-Structured FS, a mapping table is always needed,
such as inode map, DAT, etc. When a update operation happens for this
mapping table, is it actually a kind of over-write? If it is, is it a
bottleneck for the performance of write for SSD?

What do you think the major work that BTRFS can do to improve the
performance for SSD? I know FTL has becomes smarter and smarter, the
idea of log-structured file system is always implemented inside the
SSD by FTL, in that case, it sounds all the issues have been solved no
matter what the FS it is in upper stack. But at least, from the
results of benchmarks on the internet show that the performance from
different FS are quite different, such as NILFS2 and BTRFS.

Any comments?

Thanks,
Yuehai

Re: BTRFS && SSD

[Sean Bartell]

On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
> I know BTRFS is a kind of Log-structured File System, which doesn't do
> overwrite. Here is my question, suppose file A is overwritten by A',
> instead of writing A' to the original place of A, a new place is
> selected to store it. However, we know that the address of a file
> should be recorded in its inode. In such case, the corresponding part
> in inode of A should update from the original place A to the new place
> A', is this a kind of overwrite actually? I think no matter what
> design it is for Log-Structured FS, a mapping table is always needed,
> such as inode map, DAT, etc. When a update operation happens for this
> mapping table, is it actually a kind of over-write? If it is, is it a
> bottleneck for the performance of write for SSD?

In btrfs, this is solved by doing the same thing for the inode--a new
place for the leaf holding the inode is chosen. Then the parent of the
leaf must point to the new position of the leaf, so the parent is moved,
and the parent's parent, etc. This goes all the way up to the
superblocks, which are actually overwritten one at a time.

> What do you think the major work that BTRFS can do to improve the
> performance for SSD? I know FTL has becomes smarter and smarter, the
> idea of log-structured file system is always implemented inside the
> SSD by FTL, in that case, it sounds all the issues have been solved no
> matter what the FS it is in upper stack. But at least, from the
> results of benchmarks on the internet show that the performance from
> different FS are quite different, such as NILFS2 and BTRFS.

Re: BTRFS && SSD

[Yuehai Xu]

On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell <wingedtachikoma@gmail.com> wrote:
> On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
>> I know BTRFS is a kind of Log-structured File System, which doesn't do
>> overwrite. Here is my question, suppose file A is overwritten by A',
>> instead of writing A' to the original place of A, a new place is
>> selected to store it. However, we know that the address of a file
>> should be recorded in its inode. In such case, the corresponding part
>> in inode of A should update from the original place A to the new place
>> A', is this a kind of overwrite actually? I think no matter what
>> design it is for Log-Structured FS, a mapping table is always needed,
>> such as inode map, DAT, etc. When a update operation happens for this
>> mapping table, is it actually a kind of over-write? If it is, is it a
>> bottleneck for the performance of write for SSD?
>
> In btrfs, this is solved by doing the same thing for the inode--a new
> place for the leaf holding the inode is chosen. Then the parent of the
> leaf must point to the new position of the leaf, so the parent is moved,
> and the parent's parent, etc. This goes all the way up to the
> superblocks, which are actually overwritten one at a time.

You mean that there is no over-write for inode too, once the inode
need to be updated, this inode is actually written to a new place
while the only thing to do is to change the point of its parent to
this new place. However, for the last parent, or the superblock, does
it need to be overwritten?

I am afraid I don't quite understand the meaning of your last sentence.

Thanks for replying,
Yuehai


>
>> What do you think the major work that BTRFS can do to improve the
>> performance for SSD? I know FTL has becomes smarter and smarter, the
>> idea of log-structured file system is always implemented inside the
>> SSD by FTL, in that case, it sounds all the issues have been solved no
>> matter what the FS it is in upper stack. But at least, from the
>> results of benchmarks on the internet show that the performance from
>> different FS are quite different, such as NILFS2 and BTRFS.
>

Re: BTRFS && SSD

[Sean Bartell]

On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote:
> On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell <wingedtachikoma@gmail.com> wrote:
> > On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
> >> I know BTRFS is a kind of Log-structured File System, which doesn't do
> >> overwrite. Here is my question, suppose file A is overwritten by A',
> >> instead of writing A' to the original place of A, a new place is
> >> selected to store it. However, we know that the address of a file
> >> should be recorded in its inode. In such case, the corresponding part
> >> in inode of A should update from the original place A to the new place
> >> A', is this a kind of overwrite actually? I think no matter what
> >> design it is for Log-Structured FS, a mapping table is always needed,
> >> such as inode map, DAT, etc. When a update operation happens for this
> >> mapping table, is it actually a kind of over-write? If it is, is it a
> >> bottleneck for the performance of write for SSD?
> >
> > In btrfs, this is solved by doing the same thing for the inode--a new
> > place for the leaf holding the inode is chosen. Then the parent of the
> > leaf must point to the new position of the leaf, so the parent is moved,
> > and the parent's parent, etc. This goes all the way up to the
> > superblocks, which are actually overwritten one at a time.
> 
> You mean that there is no over-write for inode too, once the inode
> need to be updated, this inode is actually written to a new place
> while the only thing to do is to change the point of its parent to
> this new place. However, for the last parent, or the superblock, does
> it need to be overwritten?

Yes. The idea of copy-on-write, as used by btrfs, is that whenever
*anything* is changed, it is simply written to a new location. This
applies to data, inodes, and all of the B-trees used by the filesystem.
However, it's necessary to have *something* in a fixed place on disk
pointing to everything else. So the superblocks can't move, and they are
overwritten instead.

Re: BTRFS && SSD

[Yuehai Xu]

On Wed, Sep 29, 2010 at 3:59 PM, Sean Bartell <wingedtachikoma@gmail.com> wrote:
> On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote:
>> On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell <wingedtachikoma@gmail.com> wrote:
>> > On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
>> >> I know BTRFS is a kind of Log-structured File System, which doesn't do
>> >> overwrite. Here is my question, suppose file A is overwritten by A',
>> >> instead of writing A' to the original place of A, a new place is
>> >> selected to store it. However, we know that the address of a file
>> >> should be recorded in its inode. In such case, the corresponding part
>> >> in inode of A should update from the original place A to the new place
>> >> A', is this a kind of overwrite actually? I think no matter what
>> >> design it is for Log-Structured FS, a mapping table is always needed,
>> >> such as inode map, DAT, etc. When a update operation happens for this
>> >> mapping table, is it actually a kind of over-write? If it is, is it a
>> >> bottleneck for the performance of write for SSD?
>> >
>> > In btrfs, this is solved by doing the same thing for the inode--a new
>> > place for the leaf holding the inode is chosen. Then the parent of the
>> > leaf must point to the new position of the leaf, so the parent is moved,
>> > and the parent's parent, etc. This goes all the way up to the
>> > superblocks, which are actually overwritten one at a time.
>>
>> You mean that there is no over-write for inode too, once the inode
>> need to be updated, this inode is actually written to a new place
>> while the only thing to do is to change the point of its parent to
>> this new place. However, for the last parent, or the superblock, does
>> it need to be overwritten?
>
> Yes. The idea of copy-on-write, as used by btrfs, is that whenever
> *anything* is changed, it is simply written to a new location. This
> applies to data, inodes, and all of the B-trees used by the filesystem.
> However, it's necessary to have *something* in a fixed place on disk
> pointing to everything else. So the superblocks can't move, and they are
> overwritten instead.
>

So, is it a bottleneck in the case of SSD since the cost for over
write is very high? For every write, I think the superblocks should be
overwritten, it might be much more frequent than other common blocks
in SSD, even though SSD will do wear leveling inside by its FTL.

What I current know is that for Intel x25-V SSD, the write throughput
of BTRFS is almost 80% less than the one of EXT3 in the case of
PostMark. This really confuses me.

Thanks,
Yuehai

Re: BTRFS && SSD

[Sander]

Yuehai Xu wrote (ao):
> So, is it a bottleneck in the case of SSD since the cost for over
> write is very high? For every write, I think the superblocks should be
> overwritten, it might be much more frequent than other common blocks
> in SSD, even though SSD will do wear leveling inside by its FTL.

The FTL will make sure the write cycles are evenly divided among the
physical blocks, regardless of how often you overwrite a single spot on
the fs.

> What I current know is that for Intel x25-V SSD, the write throughput
> of BTRFS is almost 80% less than the one of EXT3 in the case of
> PostMark. This really confuses me.

Can you show the script you use to test this, provide some info
regarding your setup, and show the numbers you see?

	Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: BTRFS && SSD

[Yuehai Xu]

On Thu, Sep 30, 2010 at 3:15 AM, Sander <sander@humilis.net> wrote:
> Yuehai Xu wrote (ao):
>> So, is it a bottleneck in the case of SSD since the cost for over
>> write is very high? For every write, I think the superblocks should =
be
>> overwritten, it might be much more frequent than other common blocks
>> in SSD, even though SSD will do wear leveling inside by its FTL.
>
> The FTL will make sure the write cycles are evenly divided among the
> physical blocks, regardless of how often you overwrite a single spot =
on
> the fs.
>
>> What I current know is that for Intel x25-V SSD, the write throughpu=
t
>> of BTRFS is almost 80% less than the one of EXT3 in the case of
>> PostMark. This really confuses me.
>
> Can you show the script you use to test this, provide some info
> regarding your setup, and show the numbers you see?

My test case for PostMark is:
set file size 9216 15360 (file size from 9216 bytes to 15360 bytes)
set number 50000(file number is 50000)

write throughput(MB/s) for different file systems in Intel SSD X25-V:
EXT3: 28.09
NILFS2: 10
BTRFS: 17.35
EXT4: 31.04
XFS: 11.56
REISERFS: 28.09
EXT2: 15.94

Thanks,
Yuehai
>
> =A0 =A0 =A0 =A0Sander
>
> --
> Humilis IT Services and Solutions
> http://www.humilis.net
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BTRFS && SSD

[Sander]

Yuehai Xu wrote (ao):
> On Thu, Sep 30, 2010 at 3:15 AM, Sander <sander@humilis.net> wrote:
> > Yuehai Xu wrote (ao):
> >> So, is it a bottleneck in the case of SSD since the cost for over
> >> write is very high? For every write, I think the superblocks should be
> >> overwritten, it might be much more frequent than other common blocks
> >> in SSD, even though SSD will do wear leveling inside by its FTL.
> >
> > The FTL will make sure the write cycles are evenly divided among the
> > physical blocks, regardless of how often you overwrite a single spot on
> > the fs.
> >
> >> What I current know is that for Intel x25-V SSD, the write throughput
> >> of BTRFS is almost 80% less than the one of EXT3 in the case of
> >> PostMark. This really confuses me.
> >
> > Can you show the script you use to test this, provide some info
> > regarding your setup, and show the numbers you see?
> 
> My test case for PostMark is:
> set file size 9216 15360 (file size from 9216 bytes to 15360 bytes)
> set number 50000(file number is 50000)
> 
> write throughput(MB/s) for different file systems in Intel SSD X25-V:
> EXT3: 28.09
> NILFS2: 10
> BTRFS: 17.35
> EXT4: 31.04
> XFS: 11.56
> REISERFS: 28.09
> EXT2: 15.94

And your testscript? You'll have to provide information on how you
create the filesystems (partitioning, etc), how you mount (options),
what versions of kernel, tools, etc, if you reboot between runs, how
many runs (also per fs), did you burn in the ssd before, modules loaded,
type and amount of hardware (controller, cpu, memory) etc, etc, etc.

	Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: BTRFS && SSD

[David Brown]

On 29/09/2010 23:31, Yuehai Xu wrote:
> On Wed, Sep 29, 2010 at 3:59 PM, Sean Bartell<wingedtachikoma@gmail.com>  wrote:
>> On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote:
>>> On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell<wingedtachikoma@gmail.com>  wrote:
>>>> On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
>>>>> I know BTRFS is a kind of Log-structured File System, which doesn't do
>>>>> overwrite. Here is my question, suppose file A is overwritten by A',
>>>>> instead of writing A' to the original place of A, a new place is
>>>>> selected to store it. However, we know that the address of a file
>>>>> should be recorded in its inode. In such case, the corresponding part
>>>>> in inode of A should update from the original place A to the new place
>>>>> A', is this a kind of overwrite actually? I think no matter what
>>>>> design it is for Log-Structured FS, a mapping table is always needed,
>>>>> such as inode map, DAT, etc. When a update operation happens for this
>>>>> mapping table, is it actually a kind of over-write? If it is, is it a
>>>>> bottleneck for the performance of write for SSD?
>>>>
>>>> In btrfs, this is solved by doing the same thing for the inode--a new
>>>> place for the leaf holding the inode is chosen. Then the parent of the
>>>> leaf must point to the new position of the leaf, so the parent is moved,
>>>> and the parent's parent, etc. This goes all the way up to the
>>>> superblocks, which are actually overwritten one at a time.
>>>
>>> You mean that there is no over-write for inode too, once the inode
>>> need to be updated, this inode is actually written to a new place
>>> while the only thing to do is to change the point of its parent to
>>> this new place. However, for the last parent, or the superblock, does
>>> it need to be overwritten?
>>
>> Yes. The idea of copy-on-write, as used by btrfs, is that whenever
>> *anything* is changed, it is simply written to a new location. This
>> applies to data, inodes, and all of the B-trees used by the filesystem.
>> However, it's necessary to have *something* in a fixed place on disk
>> pointing to everything else. So the superblocks can't move, and they are
>> overwritten instead.
>>
>
> So, is it a bottleneck in the case of SSD since the cost for over
> write is very high? For every write, I think the superblocks should be
> overwritten, it might be much more frequent than other common blocks
> in SSD, even though SSD will do wear leveling inside by its FTL.
>

SSDs already do copy-on-write.  They can't change small parts of the 
data in a block, but have to re-write the block.  While that could be 
done by reading the whole erase block to a ram buffer, changing the 
data, erasing the flash block, then re-writing, this is not what happens 
in practice.  To make efficient use of write blocks that are smaller 
than erase blocks, and to provide wear levelling, the flash disk will 
implement a small change to a block by writing a new copy of the 
modified block to a different part of the flash, then updating its block 
indirection tables.

BTRFS just makes this process a bit more explicit (except for superblock 
writes).

> What I current know is that for Intel x25-V SSD, the write throughput
> of BTRFS is almost 80% less than the one of EXT3 in the case of
> PostMark. This really confuses me.
>

Different file systems have different strengths and weaknesses.  I 
haven't actually tested BTRFS much, but my understanding is that it will 
be significantly slower than EXT in certain cases, such as small 
modifications to large files (since copy-on-write means a lot of extra 
disk activity in such cases).  But for other things it is faster.  Also 
remember that BTRFS is under development - optimising for raw speed 
comes at a lower priority than correctness and safety of data, and 
implementation of BTRFS features.  Once everyone is happy with the 
stability of the file system and its functionality and tools, you can 
expect the speed to improve somewhat over time.

Re: BTRFS && SSD

[Yuehai Xu]

On Thu, Sep 30, 2010 at 3:51 AM, David Brown <david@westcontrol.com> wr=
ote:
> On 29/09/2010 23:31, Yuehai Xu wrote:
>>
>> On Wed, Sep 29, 2010 at 3:59 PM, Sean Bartell<wingedtachikoma@gmail.=
com>
>> =A0wrote:
>>>
>>> On Wed, Sep 29, 2010 at 02:45:29PM -0400, Yuehai Xu wrote:
>>>>
>>>> On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell<wingedtachikoma@gmai=
l.com>
>>>> =A0wrote:
>>>>>
>>>>> On Wed, Sep 29, 2010 at 11:30:14AM -0400, Yuehai Xu wrote:
>>>>>>
>>>>>> I know BTRFS is a kind of Log-structured File System, which does=
n't do
>>>>>> overwrite. Here is my question, suppose file A is overwritten by=
 A',
>>>>>> instead of writing A' to the original place of A, a new place is
>>>>>> selected to store it. However, we know that the address of a fil=
e
>>>>>> should be recorded in its inode. In such case, the corresponding=
 part
>>>>>> in inode of A should update from the original place A to the new=
 place
>>>>>> A', is this a kind of overwrite actually? I think no matter what
>>>>>> design it is for Log-Structured FS, a mapping table is always ne=
eded,
>>>>>> such as inode map, DAT, etc. When a update operation happens for=
 this
>>>>>> mapping table, is it actually a kind of over-write? If it is, is=
 it a
>>>>>> bottleneck for the performance of write for SSD?
>>>>>
>>>>> In btrfs, this is solved by doing the same thing for the inode--a=
 new
>>>>> place for the leaf holding the inode is chosen. Then the parent o=
f the
>>>>> leaf must point to the new position of the leaf, so the parent is
>>>>> moved,
>>>>> and the parent's parent, etc. This goes all the way up to the
>>>>> superblocks, which are actually overwritten one at a time.
>>>>
>>>> You mean that there is no over-write for inode too, once the inode
>>>> need to be updated, this inode is actually written to a new place
>>>> while the only thing to do is to change the point of its parent to
>>>> this new place. However, for the last parent, or the superblock, d=
oes
>>>> it need to be overwritten?
>>>
>>> Yes. The idea of copy-on-write, as used by btrfs, is that whenever
>>> *anything* is changed, it is simply written to a new location. This
>>> applies to data, inodes, and all of the B-trees used by the filesys=
tem.
>>> However, it's necessary to have *something* in a fixed place on dis=
k
>>> pointing to everything else. So the superblocks can't move, and the=
y are
>>> overwritten instead.
>>>
>>
>> So, is it a bottleneck in the case of SSD since the cost for over
>> write is very high? For every write, I think the superblocks should =
be
>> overwritten, it might be much more frequent than other common blocks
>> in SSD, even though SSD will do wear leveling inside by its FTL.
>>
>
> SSDs already do copy-on-write. =A0They can't change small parts of th=
e data in
> a block, but have to re-write the block. =A0While that could be done =
by
> reading the whole erase block to a ram buffer, changing the data, era=
sing
> the flash block, then re-writing, this is not what happens in practic=
e. =A0To
> make efficient use of write blocks that are smaller than erase blocks=
, and
> to provide wear levelling, the flash disk will implement a small chan=
ge to a
> block by writing a new copy of the modified block to a different part=
 of the
> flash, then updating its block indirection tables.

Yes, the FTL inside the SSDs will do such kind of job, and the
overhead should be small once the block mapping is page-level mapping,
however, the size of page-level mapping is too large to be stored
totally in the SRAM of SSDs, So, many complicated algorithms have been
developed to optimize this. In another word, SSDs might not always be
smart enough to do wear leveling with small overhead. This is my
subjective opinion.

>
> BTRFS just makes this process a bit more explicit (except for superbl=
ock
> writes).

As you have said, the superblocks should be over written, is it
frequent? If it is, is it possible to be potential bottleneck for the
throughput of SSDs? Afterall, SSDs are not happy with over-write. Of
course, few people really knows what's the algorithms really are for
the FTL, which determines the efficiency of SSDs actually.


>
>> What I current know is that for Intel x25-V SSD, the write throughpu=
t
>> of BTRFS is almost 80% less than the one of EXT3 in the case of
>> PostMark. This really confuses me.
>>
>
> Different file systems have different strengths and weaknesses. =A0I =
haven't
> actually tested BTRFS much, but my understanding is that it will be
> significantly slower than EXT in certain cases, such as small modific=
ations
> to large files (since copy-on-write means a lot of extra disk activit=
y in
> such cases). =A0But for other things it is faster. =A0Also remember t=
hat BTRFS
> is under development - optimising for raw speed comes at a lower prio=
rity
> than correctness and safety of data, and implementation of BTRFS feat=
ures.
> =A0Once everyone is happy with the stability of the file system and i=
ts
> functionality and tools, you can expect the speed to improve somewhat=
 over
> time.

My test case for PostMark is:
set file size 9216 15360 (file size from 9216 bytes to 15360 bytes)
set number 50000(file number is 50000)

write throughput(MB/s) for different file systems in Intel SSD X25-V:
EXT3: 28.09
NILFS2: 10
BTRFS: 17.35
EXT4: 31.04
XFS: 11.56
REISERFS: 28.09
EXT2: 15.94

Thanks,
Yuehai

>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs=
" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BTRFS && SSD

[Aryeh Gregor]

On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell <wingedtachikoma@gmail.com> wrote:
> In btrfs, this is solved by doing the same thing for the inode--a new
> place for the leaf holding the inode is chosen. Then the parent of the
> leaf must point to the new position of the leaf, so the parent is moved,
> and the parent's parent, etc. This goes all the way up to the
> superblocks, which are actually overwritten one at a time.

Sorry for the useless question, but just out of curiosity: doesn't
this mean that btrfs has to do quite a lot more writes than ext4 for
small file operations?  E.g., if you append one block to a file, like
a log file, then ext3 should have to do about three writes: data,
metadata, and journal (and the latter is always sequential, so it's
cheap).  But btrfs will need to do more, rewriting parent nodes all
the way up the line for both the data and metadata blocks.  Why
doesn't this hurt performance a lot?

Re: BTRFS && SSD

[Sean Bartell]

On Wed, Sep 29, 2010 at 03:39:07PM -0400, Aryeh Gregor wrote:
> On Wed, Sep 29, 2010 at 1:08 PM, Sean Bartell <wingedtachikoma@gmail.com> wrote:
> > In btrfs, this is solved by doing the same thing for the inode--a new
> > place for the leaf holding the inode is chosen. Then the parent of the
> > leaf must point to the new position of the leaf, so the parent is moved,
> > and the parent's parent, etc. This goes all the way up to the
> > superblocks, which are actually overwritten one at a time.
> 
> Sorry for the useless question, but just out of curiosity: doesn't
> this mean that btrfs has to do quite a lot more writes than ext4 for
> small file operations?  E.g., if you append one block to a file, like
> a log file, then ext3 should have to do about three writes: data,
> metadata, and journal (and the latter is always sequential, so it's
> cheap).  But btrfs will need to do more, rewriting parent nodes all
> the way up the line for both the data and metadata blocks.  Why
> doesn't this hurt performance a lot?

For a single change, it does write more. However, there are usually many
changes to children being performed at once, which only require one
change to the parent. Since it's moving everything to new places, btrfs
also has much more control over where writes occur, so all the leaves
and parents can be written sequentially. ext3 is a slave to the current
locations on disk.

Re: BTRFS && SSD

[Yuehai Xu]

Hi,

On Wed, Sep 29, 2010 at 11:37 AM, Dipl.-Ing. Michael Niederle
<mniederle@gmx.at> wrote:
> Hi Yuehai!
>
> I tested nilfs2 and btrfs for the use with flash based pen drives.
>
> nilfs2 performed incredibly well as long as there were enough free blocks. But
> the garbage collector of nilfs used too much IO-bandwidth to be useable (with
> slow-write flash devices).

I also tested the performance of write for INTEL X25-V SSD by
postmark, the results are totally different from the results of INTEL
X25-M(http://www.usenix.org/event/lsf08/tech/shin_SSD.pdf). In his
test, the performance of NILFS2 is the best over all, however, in my
test, ext3 is the best while NILFS2 is the worst, almost 10 times less
than ext3 for the throughput of write.

So, what's the role of file system to handle these tricky storage?
Different throughput might be gotten by different file system.

The question is why nilfs2 and btrfs perform so well compared with
ext3 without considering my results, here I just talk about SSD, since
the FTL internal should always do the same thing as the file system,
that redirects the write to a new place instead of writing to the
original place. The throughput for different file system should be
more or less the same.



>
> btrfs on the other side performed very well - a lot better than conventional
> file systems like ext2/3 or reiserfs. After switching the mount-options to
> "noatime" I was able to run a complete Linux system from a (quite slow) pen
> drive without (much) problems. Performance on a fast pen drive is great. I'm
> using btrfs as the root file system on a daily basis since last Christmas
> without running into any problems.
>

The performance of file system is determined by the internal structure
of SSD? or by the structure of file system? or by the coordination of
both file system and SSD?

Thanks very much for replying.

> Greetings, Michael
>

Thanks,
Yuehai