Re: SSD and non-SSD Suitability

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

Jiro SEKIBA wrote:

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

I understand what you meant. I just wanted to know when those hacks may 
be implemented and be available for those of us interested in using 
nilfs to optimize write-heavy workloads.

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

Interesting. So nilfs' suitability for write heavy loads is actually 
quite limited on mechanical disks, as it isn't suitable for append-heavy 
situations such as databases and logging, but for use-cases that are 
write+delete heavy such as mail servers or other spool type loads it 
should still be advantageous.

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

What about enabling garbage collection, but disabling degragmentation? 
De-allocating space that isn't used any more is a necessary evil, but 
defragmentation is rather pointless in a lot of cases (e.g. SSDs) and 
counter-productive in others (mechanical disks under heavy load). Also, 
what about making the garbage collector "lazy", so that it runs either 
just-in time to overwrite discarded data (worst case scenario) or runs 
when the disks are idle (e.g. at ionice -c3, and even that only when 
there have been no disk transactions for, some selectable number of ms)?

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