On 2014-08-01 02:02, Harshavardhana wrote: On Thu, Jul 31, 2014 at 11:31 AM,
Anders Blomdell
anders.blomd...@control.lth.se wrote:
During rsync of 35 files, memory consumption of glusterfs
rose to 12 GB (after approx 14 hours), I take it that this is a
bug I should try to track down?
On 2014-08-01 08:56, Pranith Kumar Karampuri wrote:
On 08/01/2014 12:09 PM, Anders Blomdell wrote:
On 2014-08-01 02:02, Harshavardhana wrote: On Thu, Jul 31, 2014 at 11:31
AM, Anders Blomdell
anders.blomd...@control.lth.se wrote:
During rsync of 35 files, memory consumption of
On 08/01/2014 10:53 AM, Pranith Kumar Karampuri wrote:
hi,
If there are no more comments, could we take
http://review.gluster.com/#/c/8343 in.
Thanks, have merged the patch.
-Vijay
___
Gluster-devel mailing list
Gluster-devel@gluster.org
hi,
Does anyone know why there is different code for resolution in
fuse vs server? There are some differences too, like server asserts
about the resolution types like RESOLVE_MUST/RESOLVE_NOT etc where as
fuse doesn't do any such thing. Wondering if there is any reason why the
code is
On 07/31/2014 05:07 PM, Niels de Vos wrote:
On Thu, Jul 31, 2014 at 04:06:46AM -0700, Gluster Build System wrote:
SRC: http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.5.2.tar.gz
Bugs that have been marked for 3.5.2 and did not get fixed with this
release, are being moved to the
- Original Message -
From: Anders Blomdell anders.blomd...@control.lth.se
To: Pranith Kumar Karampuri pkara...@redhat.com, Gluster Devel
gluster-devel@gluster.org, Harshavardhana har...@harshavardhana.net,
Raghavendra Gowdappa rgowd...@redhat.com
Sent: Friday, 1 August, 2014 7:39:55 AM
There are subtle differences between fuse and server. In fuse the inode
table does not use LRU pruning, so expected inodes are guaranteed to be
cached. For e.g, when mkdir() FOP arrives, fuse would have already checked
with a lookup and the kernel guarantees another thread would not have
created