Re: SSD and non-SSD Suitability

[David Arendt <admin-/LHdS3kC8BfYtjvyW6yDsg@public.gmane.org>]

Hi,

On 05/29/10 09:31, Jiro SEKIBA wrote:
> Hi,
>
> At Fri, 28 May 2010 10:50:31 +0100,
> Gordan Bobic wrote:
>   
>> 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?
>>     
> I don't know well about btrfs, but I guess you can create a "snapshot"
> of current filesystem.  You can not create yesterday's snapshot.
> While nilfs can do the trick :) to create snapshot of yesterday's
> filessytem state.
>
> Nilfs creates snapshots from checkpoints.  Checkpoints are created
> automatically almost each time filesystem changed (it depends how frequently
> system changed). If you leave the checkpoints as its are, garbage collector
> will collect those as free diskspace.  Until then, the checkpoints are
> reachable by making it as snapshot.
>
>
>   
>>>> 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?
>>     
> I might choose the wrong word, but what I meant is more hack is required
> to improve write performance.  Not just configuration matters :(.
>
>   
>>>> 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.
>>     
> Indeed. maybe /var type of directories too.
>
>   
>>>> 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?
>>     
> You can simply kill the nilfs_clearnerd after you mount the nilfs partition.
>   
If you use the latest nilfs_utils, killing nilfs_cleanerd is no longer
necessary. You can use mount -o nogc. This will not start
nilfs_cleanerd. Another possibility is to let nilfs_cleanerd start and
tweak min_free_segments and max_free_segments so that cleanerd will only
do cleaning if necessary.
> This case, of course, any garbage is reclaimed and finally end up with
> disk full, even size of files don't occupy the storage size.
>
> I don't have data for now, but it made about twice better write performance
> compared with "with garbage collector".
>
> thanks,
>
> regards,
>
>   
>>>> 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
>>
>>
>>
>>     
>
>
>
>   
Bye,
David Arendt
--
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