From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gordan Bobic Subject: Re: SSD and non-SSD Suitability Date: Fri, 28 May 2010 10:50:31 +0100 Message-ID: <4BFF91E7.9000102@bobich.net> References: <4BFCF55A.80205@bobich.net> <87typspmiq.wl%jir@sekiba.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <87typspmiq.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: > 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