Re: SSD and non-SSD Suitability

[Jiro SEKIBA <jir-hfpbi5WX9J54Eiagz67IpQ@public.gmane.org>]

Hi, Gordan

I haven't got any particular quantitative data by my own,
so I'll write somewhat subjective opinion.

At Wed, 26 May 2010 11:18:02 +0100,
Gordan Bobic wrote:
> 
> I've got a somewhat broad question on the suitability of nilfs for 
> various workloads and different backing storage devices. From what I 
> understand from the documentation available, the idea is to always write 
> sequentially, and thus avoid slow random writes on old/naive SSDs. Hence 
> I have a few questions.
> 
> 1) Modern SSDs (e.g. Intel) do this logical/physical mapping internally, 
> so that the writes happen sequentially anyway. Does nilfs demonstrably 
> provide additional benefits on such modern SSDs with sensible firmware?

In terms of writing performance, it may not have additional benefits I guess.
However, it still have benefits with regard to continuous snapshots.
It's nothing to do with SSD though.

> 2) Mechanical disks suffer from slow random writes (or any random 
> operation for that matter), too. Do the benefits of nilfs show in random 
> write performance on mechanical disks?

I think it may have benefits, for nilfs will write sequentially whatever
data is located before writing it.  But still some tweaks might be required
to speed up compared with ordinary filsystem like ext3.

> 3) How does this affect real-world read performance if nilfs is used on 
> a mechanical disk? How much additional file fragmentation in absolute 
> terms does nilfs cause?

The data is scattered if you modified the file again and again,
but it'll be almost sequential at the creation time.  So it will
affect much if files are modified frequently.

> 4) As the data gets expired, and snapshots get deleted, this will 
> inevitably lead to fragmentation, which will de-linearize writes as they 
> have to go into whatever holes are available in the data. How does this 
> affect nilfs write performance?

For now, my understanding, nilfs garbage collector moves the live (in use)
blocks to the end of logs, so holes are not created (it is correct?).
However, it leads another issue that garbage collector process, which is
nilfs_cleanerd, will consume the I/O.  This is major I/O performance
bottle neck current implementation.

> 5) How does the specific writing amount measure against other file 
> systems (I'm specifically interested in comparisons vs. ext2). What I 
> mean by specific writing amount is for writing, say, 100,000 random 
> sized files, how many write operations and MBs (or sectors) of writes 
> are required for the exact same operation being performed on nilfs and 
> ext2 (e.g. as measured by vmstat -d).

You can find public benchmark results at the following links.
However those are a bit old and current results may differ.

http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=1
http://www.linux-mag.com/cache/7345/1.html

thanks,

regards,

> Many thanks.
> 
> Gordan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 
> 





-- 
Jiro SEKIBA <jir-hfpbi5WX9J54Eiagz67IpQ@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html