Zbr's days.
April
Sun Mon Tue Wed Thu Fri Sat
   
14
     
2008
Months
Apr
Aug Sep
Oct Nov Dec

About TODO Blog RSS Old blog Projects Gallery Notes

Mon, 14 Apr 2008

Initial network filesystem benchmark. POHMELFS vs NFS. Round 1.

Hardware (both client and server have the same hardware).
4-way (2 logical (HT) + 2 physical cpus) 3.00 Xeon (32 bits with PAE :), 8 GB of RAM, Intel 82541GI gbit adapters, Seagate ST3300007LC 10k rpm scsi disk on Adaptec AIC7902 PCI-X Ultra320 SCSI adapter.

Software.
Server: 2.6.25-rc7 kernel, in-kernel NFS server, userspace POHMELFS server.
Client: 2.6.25-rc8 kernel, in-kernel clients.
Both have all kernel debugging turned on.

Round 1. Huge directory (linux-2.6.24.4.tar archive) untarring over the network.
Picture shows it all.

POHMELFS vs NFS

Notice, that there is no test for POHMELFS reading (that is why it is only first round), since it is miserable. And I know the reason: I'm lazy, so I use generic reading function (generic_file_aio_read()), but actually Linux does not have AIO reading from usual files, so it is very synchronous and requires to read data page-by-page, so we have a pretty broken system in regards to network performance.

Since reading is not async, so I will reimplement generic_file_aio_read() as pohmelfs_aio_read(), which will be a real AIO reading function. That will be second round, where POHMELFS will win.

But it can not win the game. Because things are changing. Today I've known, that if filesystem has only 20 users over the world, then it should not be merged, since burden of changing something generic in VFS (and thus propagate it to filesystems) is too high.

What has happend? Linux kernel maintainers started to be afraid of changes? Afraid of more code? Afraid of something new they do not want?..

Eh, and they tell they want more developers... They want monkeys who will do only what was asked them to do.

POHMELFS will be sent for review of course, but it is highly unlikely I will push it upstream.

/devel/fs :: Link / Comments (6)

Anonymous wrote at 2008-04-14 20:50:

Please don't get discouraged by the initial reaction. You have done some impressive work, which I suspect *will* get merged eventually. However, you likely need at least two things before you merge: * A compelling argument across the board (for instance, performance that beats NFS on every operation, and the flexible handling of block devices you have mentioned before). * Better integration with the kernel. Rather than bypassing VFS, integrate with it, and change it as needed. Make changes that help other filesystems too.

A few more users wouldn't hurt either. :)

However, you need to cut out the "corporate linux developer" and "by the people, for the people" stuff before you permanently set off everyone's twit detector and make merging significantly harder. Linux is not a democracy, Linux is not a free-for-all, and Linux *definitely* won't merge something unless its benefits outweigh the costs of ongoing maintenance and additional complexity.

Simon wrote at 2008-04-15 00:50:

I agree with the first reply - it's nothing to do with corporate money, or any nonsense like that. It's that Linux is a huge project and correspondingly puts great value on stability - they need a compelling reason to add something new, and if something is used only by a tiny number of users (like Andrew Morton is saying), it's hard to make a case for it. The bar for inclusion is extremely high, regardless of who you are - it has been for years.

So, if you really believe in your project, get people to use it as a patch, and build up support for it. And *then* you can try making your case for kernel inclusion, when you've got a few thousand people using it, or ten thousand, rather than just twenty. Until then, you're unproven - why should they mainline a patch like this from someone with no track record, and no guarantee you'll still be willing to work on it five years from now?

rm wrote at 2008-04-15 17:14:

And stop calling it "pohmel fs" if you want to be taken seriously.

Phillip Lougher wrote at 2008-04-15 19:56:

Unfortunately I tend to agree with the poster. I too wondered what happened when I failed to get Squashfs accepted into mainline back in 2005. The rule that they go in if they're being shipped by distros is news to me. Even back in 2005 Squashfs was shipped by a significant number of distros.

The changes demanded to Squashfs in 2005 took more than a year of part-time work to finish. After I'd done the changes I realised I no longer cared that much whether it was in mainline or not. Hence I've not yet resubmitted it.

Good luck in your attempt.

anon wrote at 2008-04-26 08:05:

Cool. Nice work.

Minor nit, the graph would be clearer if you reordered the items. For example: nfs_async_disk pohmelfs_disk local_disk nfs_async_tmpfs pohmelfs_tmpfs local_tmpfs

Zbr wrote at 2008-04-26 10:48:

Yep, that's doable. Will try it with next round of benchmarks.

Please solve this captcha to be allowed to post (need to reload in a minute): 72 - 97

Name:
URL (optional):
Captcha:
Comments: