About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Tue, 25 Dec 2007

Continuing CRFS debates.

Zach Brown again shed some light on his CRFS desing and implementation. Let's compare facts with my thoughts.

The most exciting news is that CRFS caches not only data but metadata too on the client, which is flushed to server on writeback. That is what allows to have 4-6 times higher performance in metadata intensive operations.

Another news is actually quite bad for majority of the potential CRFS users - userspace server is btrfs specific, which can be another gain in the benchmarks (although should be noticebly smaller than metadata caching part). Server does not require any additional patches, but since it is btrfs specific, it likely works on top of ramdisk (when test was perfromed with RAM storage), not tmpfs. Userspace server has exclusive access to given block device, so it is not allowed to simultaneously mount it via usual way (probably it is possible to mount it read-only whlist it is used by CRFS).
Client kernel module only depends on ->write_begin()/->write_end() patchset by Nick Piggin, which was added to mainline recently.

Batching of network requests happens naturally in request/reply protocol, but reply contains not only single request, but set of them, since client caches metadata, it can check if data is in the cache or not and update it if needed.

Getting that knowledge, let's summarize given bits:

• CRFS is btrfs specific, while pohmelfs is supposed to be fs-agnostic. This CRFS feature allows to have faster (probably even noticebly faster) access to on-disk data. Do not think it is a bad sign, consider it as a client-server filesystem, no one claims AFS is bad, since there is only AFS specific kernel server. Here is the same, but server is in userspace.
  From another point of view, not allowing to work with the same btrfs volume locally can be a show-stopper for some users.
• Metadata caching. That rocks. It has to be implemented.
• Extended request/reply protocol: i.e. do not reply with only single data (if it was not explicitly requested), but try to combine objects. The most obvious example is ->readdir() callback, when each request from client should transfer multiple objects, which will then be cached.

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

Comments are closed for this story.