My little dd test is certainly not exhaustive but I’ve found it to be a pretty quick way to compare speed across disks and filesystems, but I’ll have to try other block sizes and timing the sync like you suggested.

When copying files, a 105MB file on ext3 will probably just queue the dirty pages in memory, before the data has been flushed to disk, whereas NILFS is probably super careful about not returning until all data is on the disk. This fact is borne out by the fact that both 105MB file and 1G file on NILFS are written at roughly the same rate.

I guess at as NILFS becomes more production ready, async operation would be an option on NILFS in a similar manner to ext3/ext4.

Other things you might want to try:
- Using a larger block size. 4K is small for data copying or bulk writing, and NILFS would excel in bulk writes as it does all it’s writes in sequential mode.
- After the copy the 1G file, run the sync command and see how long that takes on each file system.

The article you reference uses postmark benchmarks, which probably does file sync for each file (email servers are quite conservative when saving user data).

Being a log structured file system, files can be fragmented which can affect read performance on rotating hard disks, but is not a problem on FLASH based SSD. Of course, on an SSD, random writes are also not the problem it is on hard disks, so that benefit of NILFS is lost on SSD.

If you’re not interested in other NILFS features (the main one being the continuous snapshots) then perhaps it indeed is not for you. But don’t discount its performance until you’re sure your benchmark is comparing apples to apples. Personally, I would simply use ext3 or ext4 on an SSD if I can persuade my boss to buy me one

(Note, not affiliated in any way with NILFS project.)