DownloadGlusterFS Roadmap Suggestions
From GlusterDocumentation
Please note that if your notes are removed, it means that we have addressed your needs or we have incorporated them into our roadmap.
It would be great to export (via cifs or nfs) a folder with quota and report its quota-limit as its whole size, instead of using gluster volume size as the whole size.
--adocampo 11:10, 14 March 2012 (CET)
User quotas, directory level quotas.
--Lxndr 06:58, 5 July 2009 (PDT)
Scratch space for notes.
Translator to strink filesystems with many identical files. http://en.wikipedia.org/wiki/Single_instance_storage - of course, that should read "shrink" :). - Original request posted by Swankier on savannah BTS.
- I would like a faster local read access for long-distance afr (e.g. hosting colos all over Europe). All read ops (including directory listings) should be configurable to work directly on the local copy without triggering locks and/or autoheals over the net. The scenario has infrequent write ops, only one or two writers and many frequent readers which need fast access to the filesystem. "But you can have afr with local volume name, and have read-subvolume option set to local volume." would do the job if it would be faster and could circumvent the fuse layer. It needs to be as fast as local filesystem access. - I'd like a glusterfsck which autoheals only the sick, because "It is not the healthy [files] that need a doctor" - I'd like CHAP authentication (like iSCSI :) - I would like the AFR replicator to use the lesser of the available free space, so that it is not necessary to "make sure that the underlying filesystems have equal available disk space." - I'd like a background autoheal, with some method of determining when and whether the mirrors were disconnected. - 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
Hi, glusterfs is great, but there are a few features that I think would allow for much greater flexibility: - IPv6 Transport, we use IPv6 for the vast majority of services on our network, GlusterFS is one of the only things we still need IPv4 on our local network for. - IPv4 and IPv6 multicast transport. This could be impossible in reality as UDP can't guarantee the successful transmission of any given packet, but if it were possible, really nice things like having a multicast group for glusterfs servers on the network, and having clients simply specify the multicast address in their volfile. Combined with the distribute and afr translators this could provide a redundant, growing storage pool, where new servers simply joined the multicast group, and no reconfiguration of clients would be needed. - Also I'd like to echo what someone else said, some kind of parity translator ala raid5, would be awesome --jscinoz 23:22, 17 April 2009 (AEST)
I would like to be able to choose the number of bricks that would hold my file at the time, this would make sure that my file was accessible even if i lost a brick, and also i would be able to get more space in the FS for each brick added while still having redundancy.
Great work guys.
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)
kudos to the developers! what a promising project.
my idea is for a tiered storage. why? i can see myself adding bigger and faster bricks onto our system (in pairs). it would be great to be able to say that certain files/directories/wildcards gravitate towards certain faster/slower bricks. i'm not sure if the hashing can cope with this - but hope it can... i also would like to see a raid like translator too.
again, thanks.
