search for: poten

Hi, I have two data frames (u and v). > u   coe      nam 1   0     Time 2   0    Poten 3   0   AdvExp 4   0    Share 5   0   Change 6   0 Accounts 7   0     Work 8   0   Rating > v       coeff    enter 1 0.7272727 Accounts 2 0.3211112     Time 3 0.0500123    Poten I want to update the values of coe in u by using the values ofcoeff in v. That is, I want to get the following res...

...course, by the system itself) but the group-membership mapping only works in the shell, not with samba. Can anybody give me a hint what this problem is about? Or how i can fix it? Or at least, who i can ask? Is this a bug or did i forget something? Thank you all in advance, kind regards, Philip Poten

Hi, I operate a distributed replicated (1:2) setup that looks like this: server1:bigdisk,server1:smalldisk,server2:bigdisk,server2:smalldisk replica sets are bigdisk-bigdisk and smalldisk-smalldisk. This setup will be extended by another set of four bricks (same setup) within the next few days, and I could make those into another volume entirely, but I'd prefer not to, leaving me with more

I do not mean to be argumentative, but I have to admit a little frustration with Gluster. I know an enormous emount of effort has gone into this product, and I just can't believe that with all the effort behind it and so many people using it, it could be so fragile. So here goes. Perhaps someone here can point to the error of my ways. I really want this to work because it would be ideal

Hello, we've been using glusterfs 3.0 for a while now, and it appears to be quite stable and very useful. Next thing we need to do however is to migrate to glusterfs 3.2 to allow for brick additions on the fly without client restarts. Now, since we are about to completely re-do the whole thing, we should really do distributed replicated volumes, and here I was wondering: can I use different

Hi, We've been experiencing repeated (every other day) oopses on hosts with high load glusterfs accesses. Co-occurrent (not immediately tho, but there is some sort of connection) are hanging nginx processes (doing the accessing), which can not be stopped, killed and also block the shutdown of the respective openvz instance. I think I remember at least one instance where this occurred without