This is a brief summary of our initial filesystem performance study of f2fs against existing two filesystems in linux: EXT4, NILFS2, and f2fs.
* test platform
i) Desktop PC : Linux 3.6.1 (f2fs patched), Intel i5-2500 @3.3GHz quad-core, 8GB RAM, Transcend 16GB class 10 micro SD card
ii) Galaxy-S3 : Linux 3.0.15 (f2fs ported), Android 4.0.4, DVFS turned off, Transcend 16GB class 10 micro SD card
* experiment 1: buffered write(sequential and random, 4KByte write)
===================================================================
F2FS surpasses other two filesystems in both random and sequential. In desktop and Galaxy S3, f2fs exhibits 2.5 and 1.6 times better performance in random write against EXT4, respectively. EXT4 is standard Android filesystem.
buffered write (1GB file)
+-------+---------------------------------+----------------------------------+
| | Desktop PC | Galaxy-S3 |
| +-----------------+---------------+------------------+---------------+
| |sequential (MB/s)| random (IOPS) |sequential (MB/s) | random (IOPS) |
+-------+-----------------+---------------+------------------+---------------+
| EXT4 | 7.1 | 1073 | 6.7 | 1073 |
+-------+-----------------+---------------+------------------+---------------+
| NILFS2| 6.8 | 1462 | 4.0 | 1272 |
+-------+-----------------+---------------+------------------+---------------+
| F2FS | 10.6 | 2675 | 6.9 | 1682 |
+-------+-----------------+---------------+------------------+---------------+
* experiment 2: write + fsync(sequential and random)
====================================================
F2FS surpasses other two filesystems in both random and sequential workload. In desktop and Galaxy S3, f2fs exhibits 2 and 1.5 times better performance in write+fsync random write against EXT4, respectively.
write + fsync (100MB file)
+-------+---------------------------------+----------------------------------+
| | Desktop PC | Galaxy-S3 |
| +-----------------+---------------+------------------+---------------+
| |sequential (KB/s)| random (IOPS) |sequential (KB/s) | random (IOPS) |
+-------+-----------------+---------------+------------------+---------------+
| EXT4 | 511.8 | 125 | 383.4 | 119 |
+-------+-----------------+---------------+------------------+---------------+
| NILFS2| 545.2 | 112 | 356.7 | 72 |
+-------+-----------------+---------------+------------------+---------------+
| F2FS | 1057.9 | 240 | 772.3 | 184 |
+-------+-----------------+---------------+------------------+---------------+
write() with fsync is to test the filesystem performance under Android SQLite operation.
* experiment 3: mounting time
===============================
To measure the mount time, we used two different scenarios. First, we mounted file system after formatting without rebooting system. Second, we mounted file system after rebooting in order to ensure any data cached in memory is flushed. Overall, EXT4 shows fastest mount time, and F2FS shows second best performance; however, we observed that F2FS takes longest time to mount right after formatting.
mounting time with Transcend 16GB micro-SD
+-------+-----------------------------------+-----------------------------------+
| | Desktop PC | Galaxy-S3 |
| +-----------------+-----------------+-----------------+-----------------+
| |1st mount after | after rebooting |1st mount after | after rebooting |
| |format (msec) | (msec) |format (msec) | (msec) |
+-------+-----------------+-----------------+-----------------+-----------------+
| EXT4 | 11 | 20 | 20 | 40 |
+-------+-----------------+-----------------+-----------------+-----------------+
| NILFS2| 920 | 1013 | 1680 | 1630 |
+-------+-----------------+-----------------+-----------------+-----------------+
| F2FS | 1486 | 161 | 2280 | 1570 |
+-------+-----------------+-----------------+-----------------+-----------------+
Sooman Jeong ESOS Lab. Hanyang University.
<[email protected]>????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
Hello.
Would you share the result about random read ?
Thanks.
2012/10/16, Sooman Jeong <[email protected]>:
>
> This is a brief summary of our initial filesystem performance study of f2fs
> against existing two filesystems in linux: EXT4, NILFS2, and f2fs.
>
>
> * test platform
> i) Desktop PC : Linux 3.6.1 (f2fs patched), Intel i5-2500 @3.3GHz
> quad-core, 8GB RAM, Transcend 16GB class 10 micro SD card
> ii) Galaxy-S3 : Linux 3.0.15 (f2fs ported), Android 4.0.4, DVFS turned off,
> Transcend 16GB class 10 micro SD card
>
>
> * experiment 1: buffered write(sequential and random, 4KByte write)
> ===================================================================
>
> F2FS surpasses other two filesystems in both random and sequential. In
> desktop and Galaxy S3, f2fs exhibits 2.5 and 1.6 times better performance in
> random write against EXT4, respectively. EXT4 is standard Android
> filesystem.
>
> buffered write (1GB file)
> +-------+---------------------------------+----------------------------------+
> | | Desktop PC | Galaxy-S3
> |
> |
> +-----------------+---------------+------------------+---------------+
> | |sequential (MB/s)| random (IOPS) |sequential (MB/s) | random (IOPS)
> |
> +-------+-----------------+---------------+------------------+---------------+
> | EXT4 | 7.1 | 1073 | 6.7 | 1073
> |
> +-------+-----------------+---------------+------------------+---------------+
> | NILFS2| 6.8 | 1462 | 4.0 | 1272
> |
> +-------+-----------------+---------------+------------------+---------------+
> | F2FS | 10.6 | 2675 | 6.9 | 1682
> |
> +-------+-----------------+---------------+------------------+---------------+
>
>
> * experiment 2: write + fsync(sequential and random)
> ====================================================
>
> F2FS surpasses other two filesystems in both random and sequential workload.
> In desktop and Galaxy S3, f2fs exhibits 2 and 1.5 times better performance
> in write+fsync random write against EXT4, respectively.
>
> write + fsync (100MB file)
> +-------+---------------------------------+----------------------------------+
> | | Desktop PC | Galaxy-S3
> |
> |
> +-----------------+---------------+------------------+---------------+
> | |sequential (KB/s)| random (IOPS) |sequential (KB/s) | random (IOPS)
> |
> +-------+-----------------+---------------+------------------+---------------+
> | EXT4 | 511.8 | 125 | 383.4 | 119
> |
> +-------+-----------------+---------------+------------------+---------------+
> | NILFS2| 545.2 | 112 | 356.7 | 72
> |
> +-------+-----------------+---------------+------------------+---------------+
> | F2FS | 1057.9 | 240 | 772.3 | 184
> |
> +-------+-----------------+---------------+------------------+---------------+
>
> write() with fsync is to test the filesystem performance under Android
> SQLite operation.
>
>
> * experiment 3: mounting time
> ===============================
>
> To measure the mount time, we used two different scenarios. First, we
> mounted file system after formatting without rebooting system. Second, we
> mounted file system after rebooting in order to ensure any data cached in
> memory is flushed. Overall, EXT4 shows fastest mount time, and F2FS shows
> second best performance; however, we observed that F2FS takes longest time
> to mount right after formatting.
>
> mounting time with Transcend 16GB micro-SD
> +-------+-----------------------------------+-----------------------------------+
> | | Desktop PC | Galaxy-S3
> |
> |
> +-----------------+-----------------+-----------------+-----------------+
> | |1st mount after | after rebooting |1st mount after | after
> rebooting |
> | |format (msec) | (msec) |format (msec) | (msec)
> |
> +-------+-----------------+-----------------+-----------------+-----------------+
> | EXT4 | 11 | 20 | 20 | 40
> |
> +-------+-----------------+-----------------+-----------------+-----------------+
> | NILFS2| 920 | 1013 | 1680 | 1630
> |
> +-------+-----------------+-----------------+-----------------+-----------------+
> | F2FS | 1486 | 161 | 2280 | 1570
> |
> +-------+-----------------+-----------------+-----------------+-----------------+
>
>
> Sooman Jeong ESOS Lab. Hanyang University.
> <[email protected]>
Tue, 16 Oct 2012 15:58:59 +0900, Namjae Jeon wrote:
>Hello.
>
>Would you share the result about random read ?
>
>Thanks.
>
>2012/10/16, Sooman Jeong <[email protected]>:
>>
>> This is a brief summary of our initial filesystem performance study of f2fs
>> against existing two filesystems in linux: EXT4, NILFS2, and f2fs.
>>
>>
>> * test platform
>> i) Desktop PC : Linux 3.6.1 (f2fs patched), Intel i5-2500 @3.3GHz
>> quad-core, 8GB RAM, Transcend 16GB class 10 micro SD card
>> ii) Galaxy-S3 : Linux 3.0.15 (f2fs ported), Android 4.0.4, DVFS turned off,
>> Transcend 16GB class 10 micro SD card
>>
>>
>> * experiment 1: buffered write(sequential and random, 4KByte write)
>> ===================================================================
>>
>> F2FS surpasses other two filesystems in both random and sequential. In
>> desktop and Galaxy S3, f2fs exhibits 2.5 and 1.6 times better performance in
>> random write against EXT4, respectively. EXT4 is standard Android
>> filesystem.
>>
>> buffered write (1GB file)
>> ------------------------------------------------------------------------------
>> Desktop PC Galaxy-S3
>> ------------------------------------------------------------------------------
>> sequential (MB/s) random (IOPS) sequential (MB/s) random (IOPS)
>> ------------------------------------------------------------------------------
>> EXT4 7.1 1073 6.7 1073
>> NILFS2 6.8 1462 4.0 1272
>> F2FS 10.6 2675 6.9 1682
>> ------------------------------------------------------------------------------
>>
>>
>> * experiment 2: write + fsync(sequential and random)
>> ====================================================
>>
>> F2FS surpasses other two filesystems in both random and sequential workload.
>> In desktop and Galaxy S3, f2fs exhibits 2 and 1.5 times better performance
>> in write+fsync random write against EXT4, respectively.
>>
>> write + fsync (100MB file)
>> ------------------------------------------------------------------------------
>> Desktop PC Galaxy-S3
>> ------------------------------------------------------------------------------
>> sequential (KB/s) random (IOPS) sequential (KB/s) random (IOPS)
>> ------------------------------------------------------------------------------
>> EXT4 511.8 125 383.4 119
>> NILFS2 545.2 112 356.7 72
>> F2FS 1057.9 240 772.3 184
>> ------------------------------------------------------------------------------
>>
>> write() with fsync is to test the filesystem performance under Android
>> SQLite operation.
>>
>>
>> * experiment 3: mounting time
>> ===============================
>>
>> To measure the mount time, we used two different scenarios. First, we
>> mounted file system after formatting without rebooting system. Second, we
>> mounted file system after rebooting in order to ensure any data cached in
>> memory is flushed. Overall, EXT4 shows fastest mount time, and F2FS shows
>> second best performance; however, we observed that F2FS takes longest time
>> to mount right after formatting.
>>
>> mounting time with Transcend 16GB micro-SD
>> ---------------------------------------------------------------------------------
>> Desktop PC Galaxy-S3
>> ---------------------------------------------------------------------------------
>> 1st mount after after rebooting 1st mount after after rebooting
>> format (msec) (msec) format (msec) (msec)
>> ---------------------------------------------------------------------------------
>> EXT4 11 20 20 40
>> NILFS2 920 1013 1680 1630
>> F2FS 1486 161 2280 1570
>> ---------------------------------------------------------------------------------
>>
>>
>> Sooman Jeong ESOS Lab. Hanyang University.
>> <[email protected]>
As you have requested, I have attached result of read performance(iozone).
* experiment 4: read(sequential and random)
====================================================
F2FS shows slightly better read performance than other two filesystems in both
sequential and random workload.
buffered read (1GB file)
------------------------------------------------------------------------------
Desktop PC Galaxy-S3
------------------------------------------------------------------------------
sequential (MB/s) random (IOPS) sequential (MB/s) random (IOPS)
------------------------------------------------------------------------------
EXT4 16.4 1568 9.6 1395
NILFS2 16.6 1609 9.6 1440
F2FS 16.8 1643 9.7 1499
------------------------------------------------------------------------------
* iozone command : iozone -i 0 -i 1 -i 2 -f /mnt/ext/test.txt -s 1G -r 4k -+n -e -U /mnt/ext
Sooman Jeong
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
On Tue 2012-10-16 13:07:03, Sooman Jeong wrote:
>
> This is a brief summary of our initial filesystem performance study of f2fs against existing two filesystems in linux: EXT4, NILFS2, and f2fs.
>
Hmm, flashes are actually optimized for VFAT, right? Can you compare
against that?
What about something more complex like "untar of kernel tree"?
Ouch and... thanks for doing this.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Oct 20, 2012, at 11:22 PM, Pavel Machek wrote:
> On Tue 2012-10-16 13:07:03, Sooman Jeong wrote:
>>
>> This is a brief summary of our initial filesystem performance study of f2fs against existing two filesystems in linux: EXT4, NILFS2, and f2fs.
>>
>
> Hmm, flashes are actually optimized for VFAT, right? Can you compare
> against that?
>
Do you mean SD-cards? Because, as I can understand, "raw" flash (I mean NAND chip) hasn't any special filesystem-related optimization. Moreover, as I know, this optimization takes place in the begin of device (because FAT metadata is placed in the volume's begin). But if you have several partition on a device then you haven't any optimizations for second and next FAT partitions. So, in-place modified metadata of f2fs is placed in the begin of the volume also.
Or, maybe, do you mean some another special optimization for VFAT?
> What about something more complex like "untar of kernel tree"?
>
Yes, it is very interesting use-case. Maybe, kernel compilation can be complimentary synthetic benchmark. :-)
With the best regards,
Vyacheslav Dubeyko.
> Ouch and... thanks for doing this.
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi!
> >> This is a brief summary of our initial filesystem performance study of f2fs against existing two filesystems in linux: EXT4, NILFS2, and f2fs.
> >>
> >
> > Hmm, flashes are actually optimized for VFAT, right? Can you compare
> > against that?
> >
>
> Do you mean SD-cards? Because, as I can understand, "raw" flash (I mean NAND chip) hasn't any special filesystem-related optimization. Moreover, as I know, this optimization takes place in the begin of device (because FAT metadata is placed in the volume's begin). But if you have several partition on a device then you haven't any optimizations for second and next FAT partitions. So, in-place modified metadata of f2fs is placed in the begin of the volume also.
>
> Or, maybe, do you mean some another special optimization for VFAT?
>
I meant SD-card, sorry. Compare factory-formatted VFAT on SD card with
f2fs running on the same partition.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sun, 21 Oct 2012 12:26:38 +0200, Pavel Machek wrote:
>Hi!
>
>>>> This is a brief summary of our initial filesystem performance study of f2fs against
>>>> existing two filesystems in linux: EXT4, NILFS2, and f2fs.
>>>>
>>>
>>> Hmm, flashes are actually optimized for VFAT, right? Can you compare
>>> against that?
>>>
>>
>> Do you mean SD-cards? Because, as I can understand, "raw" flash (I mean NAND chip)
>> hasn't any special filesystem-related optimization. Moreover, as I know, this optimization
>> takes place in the begin of device (because FAT metadata is placed in the volume's begin).
>> But if you have several partition on a device then you haven't any optimizations for second
>> and next FAT partitions. So, in-place modified metadata of f2fs is placed in the begin of
>> the volume also.
>>
>>Or, maybe, do you mean some another special optimization for VFAT?
>>
>
>I meant SD-card, sorry. Compare factory-formatted VFAT on SD card with
>f2fs running on the same partition.
>
> Pavel
>--
>(english) http://www.livejournal.com/~pavelmachek
>(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi,
As requested, I compared performance of VFAT with f2fs on SD card.
Following is summary of the measurement.
VFAT shows better performance on both random write+fsync and buffered-sequential write than f2fs.
However, on buffered-random and sequential write+fsync, f2fs still exhibits better performance
than other filesystems.
* buffered write (1GB file), 4KByte write
------------------------------------------------------------------------------
Desktop PC Galaxy-S3
------------------------------------------------------------------------------
sequential (MB/s) random (IOPS) sequential (MB/s) random (IOPS)
------------------------------------------------------------------------------
EXT4 7.1 1073 6.7 1073
NILFS2 6.8 1462 4.0 1272
F2FS 10.6 2675 6.9 1682
VFAT 7.3 1108 7.3 1075
------------------------------------------------------------------------------
* write + fsync (100MB file), 4KByte write
------------------------------------------------------------------------------
Desktop PC Galaxy-S3
------------------------------------------------------------------------------
sequential (KB/s) random (IOPS) sequential (KB/s) random (IOPS)
------------------------------------------------------------------------------
EXT4 511.8 125 383.4 119
NILFS2 545.2 112 356.7 72
F2FS 1057.9 240 772.3 184
VFAT 356.5 260 474.4 373
------------------------------------------------------------------------------
* buffered read (1GB file), 4KByte read
------------------------------------------------------------------------------
Desktop PC Galaxy-S3
------------------------------------------------------------------------------
sequential (MB/s) random (IOPS) sequential (MB/s) random (IOPS)
------------------------------------------------------------------------------
EXT4 16.4 1568 9.6 1395
NILFS2 16.6 1609 9.6 1440
F2FS 16.8 1643 9.7 1499
VFAT 16.6 1592 9.6 1501
------------------------------------------------------------------------------
* iozone command : iozone -i 0 -i 1 -i 2 -f /mnt/ext/test.txt -s 1G -r 4k -+n -e -U /mnt/ext
Sooman Jeong
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay? ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m???? ????????I?
Hi!
> As requested, I compared performance of VFAT with f2fs on SD card.
> Following is summary of the measurement.
Thanks.
> VFAT shows better performance on both random write+fsync and buffered-sequential write than f2fs.
> However, on buffered-random and sequential write+fsync, f2fs still exhibits better performance
> than other filesystems.
>
>
> * buffered write (1GB file), 4KByte write
> ------------------------------------------------------------------------------
> Desktop PC Galaxy-S3
> ------------------------------------------------------------------------------
> sequential (MB/s) random (IOPS) sequential (MB/s) random (IOPS)
> ------------------------------------------------------------------------------
...
> F2FS 10.6 2675 6.9 1682
> VFAT 7.3 1108 7.3 1075
> ------------------------------------------------------------------------------
Ok, f2fs is bit faster on desktop PC and a bit slower on S3. Good.
> * write + fsync (100MB file), 4KByte write
> ------------------------------------------------------------------------------
> Desktop PC Galaxy-S3
> ------------------------------------------------------------------------------
> sequential (KB/s) random (IOPS) sequential (KB/s) random (IOPS)
> ------------------------------------------------------------------------------
> F2FS 1057.9 240 772.3 184
> VFAT 356.5 260 474.4 373
> ------------------------------------------------------------------------------
Ok, random access on VFAT is a lot faster on S3 (and only very
a bit on PC). Any idea why results are so different between PC and S3?
Does F2FS need significantly more CPU? Does F2FS need significantly
more RAM? (Booting PC with low mem= option my answer that).
Anyway, it looks like F2FS is pretty fast filesystem...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Oct 23, 2012, at 4:07 AM, Pavel Machek wrote:
> Hi!
>
>> As requested, I compared performance of VFAT with f2fs on SD card.
>> Following is summary of the measurement.
>
> Thanks.
>
>> VFAT shows better performance on both random write+fsync and buffered-sequential write than f2fs.
>> However, on buffered-random and sequential write+fsync, f2fs still exhibits better performance
>> than other filesystems.
>>
>>
>> * buffered write (1GB file), 4KByte write
>> ------------------------------------------------------------------------------
>> Desktop PC Galaxy-S3
>> ------------------------------------------------------------------------------
>> sequential (MB/s) random (IOPS) sequential (MB/s) random (IOPS)
>> ------------------------------------------------------------------------------
> ...
>> F2FS 10.6 2675 6.9 1682
>> VFAT 7.3 1108 7.3 1075
>> ------------------------------------------------------------------------------
>
> Ok, f2fs is bit faster on desktop PC and a bit slower on S3. Good.
>
>
>> * write + fsync (100MB file), 4KByte write
>> ------------------------------------------------------------------------------
>> Desktop PC Galaxy-S3
>> ------------------------------------------------------------------------------
>> sequential (KB/s) random (IOPS) sequential (KB/s) random (IOPS)
>> ------------------------------------------------------------------------------
>> F2FS 1057.9 240 772.3 184
>> VFAT 356.5 260 474.4 373
>> ------------------------------------------------------------------------------
>
> Ok, random access on VFAT is a lot faster on S3 (and only very
> a bit on PC). Any idea why results are so different between PC and S3?
> Does F2FS need significantly more CPU? Does F2FS need significantly
> more RAM? (Booting PC with low mem= option my answer that).
>
Yes, I think that f2fs really needs more CPU and memory for functioning. The f2fs keeps more metadata as VFAT, as I understand. Moreover, it manages six active logs at runtime and GC can works in background. All of it needs in more CPU power.
With the best regards,
Vyacheslav Dubeyko.
> Anyway, it looks like F2FS is pretty fast filesystem...
>
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> >> * buffered write (1GB file), 4KByte write
> >
> > Ok, f2fs is bit faster on desktop PC and a bit slower on S3. Good.
> >
> >
> >> * write + fsync (100MB file), 4KByte write
> >
> > Ok, random access on VFAT is a lot faster on S3 (and only very
> > a bit on PC). Any idea why results are so different between PC and S3?
> > Does F2FS need significantly more CPU? Does F2FS need significantly
> > more RAM? (Booting PC with low mem= option my answer that).
> Yes, I think that f2fs really needs more CPU and memory for
> functioning. The f2fs keeps more metadata as VFAT, as I
> understand. Moreover, it manages six active logs at runtime and GC
> can works in background. All of it needs in more CPU power.
Thanks for info.
Out of curiosity, how does F2FS perform on low-end SD cards (compared
to VFAT)? I know Kingstons and similar can have only single group open
for writing... VFAT still works there, does F2FS?
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html