Pranith Kumar Karampuri kirjoitti 29.01.2018 07:32:
On 29 Jan 2018 10:50 am, "Samuli Heinonen"
wrote:
Hi!
Yes, thank you for asking. I found out this line in the production
environment:
On Fri, Jan 26, 2018 at 7:27 PM, Niels de Vos wrote:
> On Fri, Jan 26, 2018 at 06:24:36PM +0530, Mohammed Rafi K C wrote:
> > Hi All,
> >
> > I'm attending both DevConf (25-28) and Fosdem (3-4). If any of you are
> > attending the conferences and would like to talk about
- Original Message -
> From: "Nithya Balachandran"
> To: "Ravishankar N"
> Cc: "Csaba Henk" , "gluster-users"
>
> Sent: Monday, January 29, 2018 10:49:43 AM
> Subject: Re: [Gluster-users] Run
- Original Message -
> From: "Pranith Kumar Karampuri"
> To: "Alan Orth"
> Cc: "gluster-users"
> Sent: Saturday, January 27, 2018 7:31:30 AM
> Subject: Re: [Gluster-users] parallel-readdir is not recognized in
On 29 Jan 2018 10:50 am, "Samuli Heinonen" wrote:
Hi!
Yes, thank you for asking. I found out this line in the production
environment:
lgetxattr("/tmp/zone2-ssd1-vmstor1.s6jvPu//.shard/f349ffbd-
a423-4fb2-b83c-2d1d5e78e1fb.32", "glusterfs.clrlk.tinode.kblocked",
Csaba,
Could this be the problem of the inodes not getting freed in the fuse
process?
Daniel,
as Ravi requested, please provide access to the statedumps. You can strip
out the filepath information.
Does your data set include a lot of directories?
Thanks,
Nithya
On 27 January 2018 at 10:23,
Hi!
Yes, thank you for asking. I found out this line in the production
environment:
lgetxattr("/tmp/zone2-ssd1-vmstor1.s6jvPu//.shard/f349ffbd-a423-4fb2-b83c-2d1d5e78e1fb.32",
"glusterfs.clrlk.tinode.kblocked", 0x7f2d7c4379f0, 4096) = -1 EPERM
(Operation not permitted)
And this one in test
Hi,
Did you find the command from strace?
On 25 Jan 2018 1:52 pm, "Pranith Kumar Karampuri"
wrote:
>
>
> On Thu, Jan 25, 2018 at 1:49 PM, Samuli Heinonen
> wrote:
>
>> Pranith Kumar Karampuri kirjoitti 25.01.2018 07:09:
>>
>>> On Thu, Jan 25,
Hello everyone,
I'm using gluster 3.13 on a Ubuntu 16.04.3 hosts. One mayor issue in combination with ubuntus rsync version 3.1.1 seems to be the rsync-call of the geo-replication.
rsync is called from the syncdaemon (as far i understood) and it creates a call like this one:
rsync -aR0