POHMELFS stands for
Parallel Optimized Host Message Exchange Layered File System.
Project moved to the new location.
Development status can be tracked in filesystem
section.
This is a high performance network filesystem with local coherent cache of data and metadata.
Its main goal is distributed parallel processing of data. Network filesystem is a client transport.
POHMELFS protocol was proven
to be superior to NFS in lots (if not all, then it is in a roadmap) operations.
Basic POHMELFS features:
- Local coherent cache for data and metadata. (Byte-range) locking. Locks were prepared
to be byte-range, but since all Linux filesystems lock the whole inode, it was
decided to lock the whole object during writing. Actual messages being sent for
locking/cache coherency protocol are byte-range, but because the whole inode is
locked, lock is cached, so range actually is equal to the inode size.
One can simultaneously write into the same page via different offsets from different
client, and every time file will be coherent on all clients which do it and on the server itself.
- Completely async processing of all events (hard and symlinks are the only exceptions) including object creation
and data reading and writing.
- Flexible object architecture optimized for network processing. Ability to create long pathes to object and remove arbitrary
huge directories in single network command.
- High performance is one of the main design goals.
- Very fast and scalable multithreaded userspace server. Being in userspace it works with any underlying filesystem
and still is much faster than async in-kernel NFS one.
- Transactions support. Full failover for all operations. Resending transactions to different servers on timeout or error.
- Client is able to switch between different servers (if one goes down, client automatically reconnects to second and so on).
- Client parallel extensions: ability to write to multiple servers and balance reading between them.
- Client dynamic server reconfiguration: ability to add/remove servers from working set in run-time.
- Strong authentification and possible data encryption in network channel.
Roadmap includes:
- Server redundancy extensions (ability to store data in multiple locations according to regexp rules, like '*.txt' in /root1 and '*.jpg' in /root1 and /root2.
- Async writing of the data from receiving kernel thread into userspace pages via copy_to_user() (check development tracking
blog for results).
- Start generic server distribution development.
One can grab sources from archive
or GIT tree
(web interface).
Usage example:
$ make
# cfg -a 192.168.0.1 -p 1025 -i 0
# cfg -a 192.168.0.2 -p 1025 -i 0
# cfg -a 192.168.0.3 -p 1025 -i 0
# mount -t pohmel -o idx=0 q /mnt
This configuration will allow client to connect to servers at 192.168.0.{1,2,3}:1025.
Server usage:
$ make
# fserver -r /mnt -w 1
Where /mnt is a working directory (server will chroot there). -w key
specifies number of worker threads. You can find more options in help.
One can find more details in Documentation/filesystems/pohmelfs/ directory.
|