[Gluster-devel] 4.0 ideas
Joe Julian
joe at julianfamily.org
Thu May 7 19:04:17 UTC 2015
On 05/07/2015 11:15 AM, Jeff Darcy wrote:
> Last week, those of us who were together in Bangalore had a meeting to
> discuss the GlusterFS 4.0 plan. Once we'd covered what's already in
> the plan[1] we had a very productive brainstorming session on what else
> we might want to consider adding. Here are some of my notes, in no
> particular order, for discussion either here on the list or in person at
> the upcoming Barcelona summit.
>
> * Traffic throttling
> Many internal services need this to keep from crowding out new user
> requests.
+1
>
> * Centralized logging
-1 There's already 3rd party applications that do that. Is that worth
the effort to duplicate something that's done very well already?
>
> * Third-party copy (server to server, at client request)
> AIUI both SMB and NFS can make such requests, which we currently must
> satisfy by "bouncing" data through the proxy node. We could add it to
> GFAPI as well, for users there who also want to avoid the extra
> network traffic.
+1!!!!!!1!111!!1!!
> * Better memory management (talloc, maybe even a real garbage collector)
+1
> * Virtual nodes (DHT feature to improve rebalance behavior)
>
> * Hot-spare nodes/bricks
-1 From what I've seen, most users are against spending money on
hardware that's not being used. An auto-rebalance, or some such
mechanism, to ensure redundancy after a failure would be much more welcome.
>
> * Better faiure detection
> Detecting failures via pairwise heartbeat (what we do now) doesn't
> work at scale. This might become part of the GlusterD v2 plan.
>
> * File level snapshots.
>
> * Finer-grain version/feature negotiation between nodes.
Or at least one that doesn't require user intervention. Right now that
mechanism sometimes fails and the user has to manually set the op-version.
>
> * Better GFID-to-path translation
>
> * Retire NFSv3
>
> * Make snapshots more modular (not solely dependent on LVM)
+1
>
> * FTP or STFP (sshfs) client using GFAPI
> I've proposed this as a potential intern project.
>
> [1] http://www.gluster.org/community/documentation/index.php/Planning40
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
More information about the Gluster-devel
mailing list