[Gluster-users] Client-side GlusterFS

[John Mark Walker]

If you feel that our strategy on the client side is broken, while I respect that opinion, its kind of a pointless discussion. We made the architectural decisions we made understanding the tradeoffs as they were - which have been enumerated on this list numerous times.

In any case, if you want to have an architectural discussion or debate, that's better directed towards gluster-devel, and that's a discussion we welcome. However, this list is gluster-users, which as the name implies, is about users of the software as it exists today, warts and all. 

Feel free to use the wiki to develop any thoughts you may have regarding ideal architectures. Even better if you can round up developers to implement said architecture.

-JM


Stephan von Krawczynski <skraw at ithnet.com> wrote:

Dear JM,

unfortunately one has to tell openly that the whole concept that is tried here
is simply wrong. The problem is not the next-bug-to-fix. The problem is the
client strategy in user space. It is broken by design. You can either believe
this or go ahead ignoring it and never really get a good and stable setup.
Really, the whole we-close-our-eyes-and-hope-it-will-turn-out-well strategy
looks just like btrfs. Read the archives, I told them years ago it will not
work out in our life time. And today, still they have no ready-for-production
fs, and believe me: it never will be there.
And the same goes for glusterfs. It _could_ be the greatest fs on earth, but
only if you accept:

1) Throw away all non-linux code. Because this war is over since long.
2) Make a kernel based client/server implementation. Because it is the only
way to acceptable performance.
3) Implement true undelete feature. Make delete a move to a deleted-files area.

These are the minimal steps to take for a real success, everything else is
just beating the dead horse. 

Regards,
Stephan



On Thu, 27 Dec 2012 10:03:10 -0500 (EST)
John Mark Walker <johnmark at redhat.com> wrote:

> Look, fuse its issues that we all know about. Either it works for you or it doesn't. If fuse bothers you that much, look into libgfapi. 
> 
> Re: NFS - I'm trying to help track this down. Please either add your comment to an existing bug or create a new ticket. 
> 
> Either way, ranting won't solve your problem or inspire anyone to fix it. 
> 
> -JM
> 
> 
> Stephan von Krawczynski <skraw at ithnet.com> wrote:
> 
> On Wed, 26 Dec 2012 22:04:09 -0800
> Joe Julian <joe at julianfamily.org> wrote:
> 
> > It would probably be better to ask this with end-goal questions instead 
> > of with a unspecified "critical feature" list and "performance problems".
> > 
> > 6 months ago, for myself and quite an extensive (and often impressive) 
> > list of users there were no missing critical features nor was there any 
> > problems with performance. That's not to say that they did not meet your 
> > design specifications, but without those specs you're the only one who 
> > could evaluate that.
> 
> Well, then the list of users does obviously not contain me ;-)
> The damn thing will only become impressive if a native kernel client module is
> done. FUSE is really a pain.
> And read my lips: the NFS implementation has general load/performance problems.
> Don't be surprised if it jumps into your face.
> Why on earth do they think linux has NFS as kernel implementation?
> -- 
> Regards,
> Stephan
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
> 


_______________________________________________
Gluster-users mailing list
Gluster-users at gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-users