Re: SSD and non-SSD Suitability

[Gordan Bobic <gordan-UpbECiGlrmGsTnJN9+BGXg@public.gmane.org>]

Jiro SEKIBA wrote:

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

Thanks, I appreciate it. :)

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

How does this compare with btrfs snapshots? When you say continuous, 
what are the breakpoints between them?

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

Can you quantify what those tweaks may be, and when they might become 
available/implemented?

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

Right. So bad for certain tasks, such as databases.

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

Since this moves files, it sounds like this could be a major issue for 
flash media since it unnecessarily creates additional writes. Can this 
be suppressed?

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

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