Re: Initial report on F2FS filesystem performance
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 -- 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: Initial report on F2FS filesystem performance
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 -- 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: Initial report on F2FS filesystem performance
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.62675 6.9 1682 >> VFAT 7.31108 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.9240 772.3 184 >> VFAT 356.5260 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 -- 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: Initial report on F2FS filesystem performance
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.62675 6.9 1682 VFAT 7.31108 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.9240 772.3 184 VFAT 356.5260 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 -- 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: Initial report on F2FS filesystem performance
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.62675 6.9 1682 > VFAT 7.31108 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.9240 772.3 184 > VFAT 356.5260 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 -- 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: Initial report on F2FS filesystem performance
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.11073 6.7 1073
NILFS2 6.81462 4.0 1272
F2FS 10.62675 6.9 1682
VFAT 7.31108 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.8125 383.4 119
NILFS2545.2112 356.7 72
F2FS 1057.9240 772.3 184
VFAT 356.5260 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.41568 9.6 1395
NILFS2 16.61609 9.6 1440
F2FS 16.81643 9.7 1499
VFAT 16.61592 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�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Initial report on F2FS filesystem performance
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.11073 6.7 1073
NILFS2 6.81462 4.0 1272
F2FS 10.62675 6.9 1682
VFAT 7.31108 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.8125 383.4 119
NILFS2545.2112 356.7 72
F2FS 1057.9240 772.3 184
VFAT 356.5260 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.41568 9.6 1395
NILFS2 16.61609 9.6 1440
F2FS 16.81643 9.7 1499
VFAT 16.61592 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�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
Re: Initial report on F2FS filesystem performance
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.62675 6.9 1682 VFAT 7.31108 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.9240 772.3 184 VFAT 356.5260 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 -- 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: Initial report on F2FS filesystem performance
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 -- 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: Initial report on F2FS filesystem performance
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 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: Initial report on F2FS filesystem performance
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 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: Initial report on F2FS filesystem performance
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 -- 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: Initial report on F2FS filesystem performance
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 -- 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: Initial report on F2FS filesystem performance
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 -- 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: Initial report on F2FS filesystem performance
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 <77sm...@hanyang.ac.kr>: >> >> 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.11073 6.7 1073 >> >> NILFS2 6.81462 4.0 1272 >> >> F2FS 10.62675 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.8125 383.4 119 >> NILFS2545.2112 356.7 72 >> F2FS 1057.9240 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 afterafter rebooting 1st mount afterafter >> rebooting >> format (msec) (msec)format (msec) (msec) >> - >> EXT411202040 >> NILFS2 920 1013 1680 1630 >> F2FS 1486 161 2280 1570 >> - >> >> >> Sooman Jeong ESOS Lab. Hanyang University. >> <77sm...@hanyang.ac.kr> 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)
Re: Initial report on F2FS filesystem performance
Hello. Would you share the result about random read ? Thanks. 2012/10/16, Sooman Jeong <77sm...@hanyang.ac.kr>: > > 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. > <77sm...@hanyang.ac.kr> -- 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: Initial report on F2FS filesystem performance
Hello. Would you share the result about random read ? Thanks. 2012/10/16, Sooman Jeong 77sm...@hanyang.ac.kr: 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. 77sm...@hanyang.ac.kr -- 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: Initial report on F2FS filesystem performance
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 77sm...@hanyang.ac.kr: 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.11073 6.7 1073 NILFS2 6.81462 4.0 1272 F2FS 10.62675 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.8125 383.4 119 NILFS2545.2112 356.7 72 F2FS 1057.9240 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 afterafter rebooting 1st mount afterafter rebooting format (msec) (msec)format (msec) (msec) - EXT411202040 NILFS2 920 1013 1680 1630 F2FS 1486 161 2280 1570 - Sooman Jeong ESOS Lab. Hanyang University. 77sm...@hanyang.ac.kr 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.41568 9.6 1395 NILFS2 16.6
