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. 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > -- Jiro SEKIBA <jir@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
