On Wed, May 14, 2008 at 01:52:23AM +0100, Jamie Lokier (jamie@shareable.org) wrote:It was (and is) also a different time zone here :) NFSv4 does not use similar caching scheme, but it has interesting batching abilities for bulk data transfer. CRFS was originally a source of inspiration for this project (before it was opened, we had some talk with Zach Brown, so I decided that it worth deeper investigation and started this FS). CRFS performance is also very good, but the fact, that it is only limited to BTRFS server seriously limits its usage imho. The more we develop, more problems arises, so it is possible (and I had such situation), when very complex, but solvable problem, during development translates into multiple problems of the same complexity, which takes more and more time... Essentially this can be solved, until something is dropped and added when other things are completed. For example there is a really interesting lockless algorithm for storing path cache in the POHMELFS, but implementation is really complex, so I used much simler tree based one, and things scale good even with it. Depending on what to call a release :) I belive that (only block?) FS which exports its structure in database accessible way, i.e. ability to search objects not only by name key and assign that new keys similar to how it is done in database, but not via assign_xattr(search(name)), is a very interesting and useful approach. Also the more I follow general purpose fs developments, the more I become sure that they (general purpose) will never be the best on any given workload, and instead special purpose (like databasefs or whatever) filesystems will get the niche. IMHO of course. Scares problems which we can not solve, this one kind of increases adrenalin level :) Yeah, probably this is time to move further in given area, so lots of interesting new developments. -- Evgeniy Polyakov --
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Greg KH | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Jarek Poplawski | Re: [BUG] New Kernel Bugs |
