From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gordan Bobic Subject: Re: SSD and non-SSD Suitability Date: Sat, 29 May 2010 09:43:35 +0100 Message-ID: <4C00D3B7.8060904@bobich.net> References: <4BFCF55A.80205@bobich.net> <87typspmiq.wl%jir@sekiba.com> <4BFF91E7.9000102@bobich.net> <87d3wf17vj.wl%jir@sekiba.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <87d3wf17vj.wl%jir-27yqGEOhnJbQT0dZR+AlfA@public.gmane.org> Sender: linux-nilfs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Jiro SEKIBA Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@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