SV: [Gluster-devel] Re-exporting NFS to vmware

2011-01-06 Thread Fredrik Widlund
with many concurrent sessions even though the storage backend support a much higher load. Kind regards, Fredrik Widlund -Ursprungligt meddelande- Från: gluster-devel-bounces+fredrik.widlund=qbrick@nongnu.org [mailto:gluster-devel-bounces+fredrik.widlund=qbrick@nongnu.org] För

SV: [Gluster-devel] Re-exporting NFS to vmware

2011-01-06 Thread Fredrik Widlund
If you're re-exporting a gluster filesystem, the re-exporting node will act as a proxy. As a concept this is fairly natural, and in itself it shouldn't be a problem. And I did say that it is possible to re-export a FUSE filesystem, not impossible. Kind regards, Fredrik Widlund

SV: SV: [Gluster-devel] Re-exporting NFS to vmware

2011-01-06 Thread Fredrik Widlund
), but in our tests both top out on around 500MB/s with a concurrent load anyways. With the gluster nfs we top out maybe 10% higher, but the difference is marginal. As far as reliability is concerned, in our experience unfs seem to be by far the worst choice. Kind regards, Fredrik Widlund

RE: [Gluster-devel] atomic operations fails_

2010-02-10 Thread Fredrik Widlund
--entry-timeout=0 did not make any visible change. Regards, Fredrik -Original Message- From: anand.av...@gmail.com [mailto:anand.av...@gmail.com] On Behalf Of Anand Avati Sent: den 10 februari 2010 05:00 To: Fredrik Widlund Cc: gluster-devel@nongnu.org Subject: Re: [Gluster-devel

RE: [Gluster-devel] atomic operations fails_

2010-02-10 Thread Fredrik Widlund
Can you reproduce this behavior on your end? Regards, Fredrik -Original Message- From: gluster-devel-bounces+fredrik.widlund=qbrick@nongnu.org [mailto:gluster-devel-bounces+fredrik.widlund=qbrick@nongnu.org] On Behalf Of Fredrik Widlund Sent: den 10 februari 2010 10:27

[Gluster-devel] atomic operations fails_

2010-02-09 Thread Fredrik Widlund
Hi, I'll try to make myself clearer than in the earlier thread, since I need some help here. I'm not sure if I am missing something. I am not able to use atomic operations using glusterfs 3.0.2, on a Arch Linux 2.6.32.7-1 x86_64 server. I've stripped everything down to the most simple

[Gluster-devel] RE: LOOKUP conflict = OPEN fails_

2010-02-08 Thread Fredrik Widlund
is that until a few days ago this problem wasn't noticeable at all, and now is huge. The only difference is the quickly growing number of files on the filesystem, now around 190k files. Kind regards, Fredrik Widlund [cid:imageaa8012.png@ec549ff3.741049af] Fredrik Widlund, CSO / Chief Architect

[Gluster-devel] RE: LOOKUP conflict = OPEN failS_

2010-02-08 Thread Fredrik Widlund
Hi, Ok, it seems to be solved for now. The writer was a pure-ftpd server, and the -O, atomic replace flag caused the behavior. I browsed through the code briefly and it uses among other things hard-link schemes to do atomic changes. Kind regards, Fredrik Widlund From: gluster-devel-bounces

SV: [Gluster-devel] RE: LOOKUP conflict = OPEN failS_

2010-02-08 Thread Fredrik Widlund
the glusterfs server into failing to read files in the posix storage, until the glusterfs server is restarted. Kind regards, Fredrik Widlund -Ursprungligt meddelande- Från: Tejas N. Bhise [mailto:te...@gluster.com] Skickat: den 8 februari 2010 20:06 Till: Fredrik Widlund Kopia: gluster