[Gluster-users] Turning GlusterFS into something else (was Re: how well will this work)

Joe Julian joe at julianfamily.org
Sun Dec 30 20:29:53 UTC 2012

On 12/30/2012 08:12 AM, Stephan von Krawczynski wrote:
> On Sun, 30 Dec 2012 10:13:52 -0500
> Jeff Darcy <jdarcy at redhat.com> wrote:
>> On 12/27/12 3:36 PM, Stephan von Krawczynski wrote:
>>> 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.
>> Sorry, but we do have non-Linux users already and won't abandon them.  We
>> wouldn't save all that much time even if we did, so it just doesn't make sense.
> Jeff, really, if you argue, please state your argument openly. You don't want
> this point because its next logical step would be my point 2), the kernel
> implementation. As long as you hold up dead boxes like orcale-owned solaris
> you have a good point in not doing 2). Success needs focussing. If you try to
> be everybody's darling you may well end up being dropped by everybody because
> you are not good enough.
>>> 2) Make a kernel based client/server implementation. Because it is the only
>>> way to acceptable performance.
>> That's an easy thing to state, but a bit harder to prove.
> Come on, how old are you? can you remember userspace-nfs? In case you cannot:
> it had just about the same problems glusterfs has today, and guess why it is
> gone...
That's not proof. Even further, that's enough iterations in the past as 
to invalidate it's example. Nothing's the same today as it was back then.
>> [a lot of bad examples deleted]
> Really, you cannot prove you are right by naming some examples that are even
> more horrible.
... he says after pointing to userspace-nfs as an example.
>>> 3) Implement true undelete feature. Make delete a move to a deleted-files area.
>> Some people want that, some people do not.
> Haha! A good argument for a config parameter :-) - I would have suggested that
> anyway.
>>   Some are even precluded from using
>> it e.g. for compliance reasons.  It's hardly a must-have feature.  In any case,
>> it already exists - called "landfill" I believe, though I'm not sure of its
>> support status or configurability via the command line.  If it didn't exist, it
>> would still be easy to create - which wouldn't be the case at all if we
>> followed your advice to put this in the kernel.
> Now I wonder how you argue about this. Let me bring in some analogy you will
> probably hate. Linux MM uses free memory to cache for just about anything
> thinkable of. This drives W*indows users crazy using Android. They always try
> to put the latest "kill-all-not-needed-apps" tool to let them read a big
> number in free space statistics. They do not understand that free memory is in
> fact wasted memory. And the same thing goes for disk space. If I delete
> something on a disk that is far from being full it is just plain dumb to
> really erase this data from the disk. It won't help anyone. It will only hurt
> you if you deleted it accidently. Read my lips: free disk space is wasted
> space, just like free mem is wasted mem.
> And _that_ is the true reason for undelete. It won't hurt anybody, and will
> help some. And since it is the true goal of a fs to organise data on a drive
> it is most obvious that "undelete" (you may call it lazy-delete) is a very
> basic fs feature and _not_ an add-on patched onto it.
It's such a very basic fs feature that it's been around since minix... 
oh, wait, no it hasn't... only now are some filesystems starting to 
become stable that use copy-on-write. Like Jeff said, it's already in 
there (nobody was using it so it hasn't gotten a lot of attention in the 
last couple of iterations).
>>   If it's a priority for you and
>> existing facilities do not suffice, then I suggest adding a feature page on the
>> wiki and/or an enhancement-request bug report, so that we can incorporate that
>> feedback into our planning process.  Thank you for your help making GlusterFS
>> better.
> [politics end]
> Jeff, this is really no technical question we are talking about. It's more a
> question of a management decision. If redhat wants a truely successful
> glusterfs someone has to decide to follow my steps. If the stuff was only
> bought because it looked interesting and no one else should use its true
> potential, well then go ahead.
Here's were you're getting labeled as a Troll. You have a tendency to do 
this on just about every mailing list except LKML (not sure why they get 
your love over others, but to each their own). You come in, spout some 
diatribe claiming how you know better than everybody else to the point 
of being told that "this is the last post I'm going to make on this 
subject". You don't work with the developers, you antagonize them. I 
still don't see the features you're asking for on the wiki, nor in bugzilla.

You obviously have some knowledge of C judging by your analysis of 
issues in LKML and patch offers relating to the same. Why not offer your 
abilities in a constructive way by using the tools we make publicly 

More information about the Gluster-users mailing list