GlusterFS Roadmap
From GlusterDocumentation
Contents |
Previous Releases
Currently available GlusterFS Features
GlusterFS 1.4 - Performance
- storage/bdb - distributed BerkeleyDB based storage backend (very efficient for small files)
- binary protocol - bit level protocol headers (huge improvement in performance for small files)
- mod_glusterfs - GlusterFS Apache / Lighttpd module (web embeddable GlusterFS)
- Non-blocking I/O - highly responsive socket I/O
Current Status: QA
GlusterFS 1.5 - High Availability / Management
- brick hot-add/remove/swap - live storage hardware maintenance
- hot-defrag - reschedule poorly scheduled files
- distributed-ns-cache - distributed name space cache
GlusterFS 1.6 - Web Interface
- features/meta - proc-like interface translator
- volume spec viewer - visual volume specification viewer
- volume spec editor - visual volume specification builder
- management console - management interface
- centralized log report - log viewer
- usage report - usage statistics
GlusterFS 1.7 and above - Features
- bond - volume bonding translator
- directory quotas - file / directory level quotas
- active self-heal - log and replay failed I/O transactions
- features/chksum - distributed checksum translator
- graid6 - cluster wide file level RAID6
- snapshot - distributed snapshot translator
- cdp - continuous data protection translator
- dedup - data de-duplication translator
- vpath - virtual path/file names
- compress - compression translator
- encrypt - encryption translator
- filter - advanced filtering policies
Request for New Feature or Priority Change
Software is best shaped by its users. We would love to hear your requirements or push certain features ahead in our development schedule. There are lot of ways to get in touch with us. Otherwise, you can use this scratch space and leave us notes quickly. We will incorporate them in our road-map. Please note that if your notes are removed, it means that we have addressed your needs or we have incorporated them into our roadmap.
Scratch space for notes. - It would be nice to remap user ID's, for example on server1 all user id's (1 - 999) map to the range 1000-1999, on server2 all user id's (1 - 999) map to 2000-2999. This would allow for better permission management without heaps of structural changes (including quotas)
- Like above, authentication would be nice. GSS-API is probably the standard for this these days. - POSIX ACL:s are perhaps not that useful; they never became an official standard, and the unix world seems to be slowly adopting NFSv4 ACL:s instead.
- multicast support at least for AFR
Just posting to put my vote in for the AmazonS3 storage translator :) Thanks!
(perhaps if enough EC2 users post their 'me-too' here we'll make an impression)
- Automount support would be a nice feature to have -> Resolved, check Howto Automount GlusterFS
You guys are doing an awesome job. Things that I would love to have in a future release: * afr as a capability of unify: It would be nice to be able to combine NUFA and afr for more flexibility. --> We have decided not to mix the functionality in any translator. But you can have afr with local volume name, and have read-subvolume option set to local volume. This should give the same functionality. * full read-only file cache with designated local storage, with a configurable minimum stat interval. --> io-cache translator does it for you (other than storing on the local disk), it has cache-revalidate timeout too. * fault management: ** configurable fault-detection settings (timeouts, retries, etc) ** fault detection instrumentation ** fault detection hooks (named-fault-event scripts in some designated directory) If I can help out in some way, let me know. Thanks for everything. Jshook 23:49, 25 May 2007 (PDT)
I'd like to echo various comments about the awesomeness of GlusterFS :) Thanks guys.
My main priorities are fault tolerance and high availability. While there's been an absolutely astounding amount of progress made in that direction already, I feel there's still issues on the client side of things.
My number one priority is non-stop IO (which was on the roadmap, but seems to have disappeared - perhaps it's been renamed?) - namely, for clients to be able to connect to pools of servers, so that if one server goes down, clients can continue IO operations, and not end up reporting transport related error messages to applications like they do now. I'm trying to emulate that externally to GlusterFS right now, but I'm not having a huge amount of luck.
Number two is active self heal, which is already at the top of the list, but I'll put in a vote in for it anyway :)
Thanks again for your great project, guys.
Geoff Kassel 13:22, 13 Sep 2007 (Australian EST)
Hello guys, just a simple request to help in debugging and maintaining the code
A more 'robust' mode of operations with internal integrity checks that can be enabled by a command line or compile time switch that enables an assertion at the top of every routine that checks the parameter passed to that routine.
I notice that assert() is not a function that is being used in glusterfs and I can see why under normal circumstances (in a kernel file system) that would not have a place but since glusterfs is running in user mode why not use the power of assert to catch the bugs as they happen instead of having to sift through large log files.
This kind of 'defensive programming' would stop the program from continuing to run with corrupted internal data structures and possibly crashing much further down the line where the relationship between the backtrace and the original bug is long lost.
For me personally being able to test with assertions enabled and running a long stress test would go a long way towards getting a higher level of confidence in the code.
A couple of comments here and there wouldn't help either :)
Jacquesm 06:01, 18 September 2007 (PDT)
--> Taken seriously, we have started with defensive programing, but to correct already working code base with all these changes may take some time, so we decided to go with gradual changes towards this direction. Thanks for the suggestion.
A note on the defensive programming/testing side - are the developers using regression testing? Reading the comment above made me wonder if there was regression testing in use - I couldn't find any framework of test cases in the code repository though.
I highly recommend it - it's a very powerful tool for maintaining program correctness with respect to known bugs/common use cases. It's also very useful for making sure that new programmer or code contributer doesn't break the important parts of your code. And there's nothing better to instill confidence in a code base, short of using formal methods.
Admittedly, it's a bit of effort to add a regression testing framework mid-project, and so it'll take some programmer time away from adding new features. Which no one wants. So I'm hoping to be able to lend some programmer time soon to adding regression testing to Gluster, since a smoothly running GlusterFS system is now a critical part of my company's hosting infrastructure.
Geoff Kassel 11:17, 04 Nov 2007 (Australian EST)
--> We had less number of devs earlier and lot of things on roadmap. But now realized that QA is very important for the product and working on our QA system to find all the corner case stability issues. Thanks for advising.
Hi, great software package! Just installed it on our cluster, working very well.
I would like to see a parity system added to the cluster/stripe translator, like a RAID-5 setup. That way we can have a high speed file-system with fault tolerance.
Thanks again for the great work you've put in.
--Robjderr 13:22, 19 November 2007 (PST)
