Yes Sanoj, that's the issue. It will somehow write the latest header which
has conf 1.2.
But for all the individual gfid's it won't work properly always. We need to
do it many times
and sometimes it will be still not set properly.
--
Thanks & Regards,
Manikandan Selvaganesan.
(@Manikandan
Thanks Sanoj for the work and pasting the work in detail.
--
Thanks & Regards,
Manikandan Selvaganesan.
(@Manikandan Selvaganesh on Web)
On Fri, Nov 11, 2016 at 3:31 PM, Manikandan Selvaganesh <
manikandancs...@gmail.com> wrote:
> Yes Sanoj, that's the issue. It will somehow write the latest
Pasting Testing Logs
==
3.6
[root@dhcp-0-112 rpms]# /sbin/gluster v create v1 $tm1:/export/sdb/br1
volume create: v1: success: please start the volume to access data
[root@dhcp-0-112 rpms]# gluster v start v1
[root@dhcp-0-112 rpms]#
[root@dhcp-0-112 rpms]# mount -t
On Thu, Nov 10, 2016 at 11:56 AM, Niels de Vos wrote:
> On Thu, Nov 10, 2016 at 11:44:21AM -0500, Vijay Bellur wrote:
>> On Thu, Nov 10, 2016 at 11:14 AM, Shyam wrote:
>> > On 11/10/2016 11:01 AM, Vijay Bellur wrote:
>> >>
>> >> On Thu, Nov 10, 2016 at
On Thu, Nov 10, 2016 at 9:33 PM, Manikandan Selvaganesh <
manikandancs...@gmail.com> wrote:
>
> No problem. As you said , glusterd_quota_limit_usage invokes the function
> which regenerates the conf file. Though I do not remember exactly, to my
> understanding when I tried, it did not work
On 11/10/2016 11:56 AM, Niels de Vos wrote:
On Thu, Nov 10, 2016 at 11:44:21AM -0500, Vijay Bellur wrote:
On Thu, Nov 10, 2016 at 11:14 AM, Shyam wrote:
On 11/10/2016 11:01 AM, Vijay Bellur wrote:
On Thu, Nov 10, 2016 at 10:49 AM, Shyam wrote:
On Thu, Nov 10, 2016 at 02:13:32PM +0530, Pranith Kumar Karampuri wrote:
> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee wrote:
>
> >
> >
> > On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
> > pkara...@redhat.com> wrote:
> >
> >> I am trying to understand the
On Thu, Nov 10, 2016 at 11:44:21AM -0500, Vijay Bellur wrote:
> On Thu, Nov 10, 2016 at 11:14 AM, Shyam wrote:
> > On 11/10/2016 11:01 AM, Vijay Bellur wrote:
> >>
> >> On Thu, Nov 10, 2016 at 10:49 AM, Shyam wrote:
> >>>
> >>>
> >>>
> >>> On 11/10/2016
On Thu, Nov 10, 2016 at 11:14 AM, Shyam wrote:
> On 11/10/2016 11:01 AM, Vijay Bellur wrote:
>>
>> On Thu, Nov 10, 2016 at 10:49 AM, Shyam wrote:
>>>
>>>
>>>
>>> On 11/10/2016 10:21 AM, Vijay Bellur wrote:
On Thu, Nov 10, 2016 at 10:16 AM,
Raghavendra,
No problem. As you said , glusterd_quota_limit_usage invokes the function
which regenerates the conf file. Though I do not remember exactly, to my
understanding when I tried, it did not work properly in my setup. It is
apparently because in the later function where we regenerate the
On Thu, Nov 10, 2016 at 10:49 AM, Shyam wrote:
>
>
> On 11/10/2016 10:21 AM, Vijay Bellur wrote:
>>
>> On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
>> wrote:
>>>
>>> Enabling/disabling quota or removing limits are the ways in which
>>>
On 11/10/2016 10:21 AM, Vijay Bellur wrote:
On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
wrote:
Enabling/disabling quota or removing limits are the ways in which quota.conf
is regenerated to the later version. It works properly. And as Pranith said,
On 10-Nov-2016 20:52, "Vijay Bellur" wrote:
>
> On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
> wrote:
> > Enabling/disabling quota or removing limits are the ways in which
quota.conf
> > is regenerated to the later version. It works
On Thu, Nov 10, 2016 at 8:46 PM, Manikandan Selvaganesh <
manikandancs...@gmail.com> wrote:
> Enabling/disabling quota or removing limits are the ways in which
> quota.conf is regenerated to the later version. It works properly. And as
> Pranith said, both enabling/disabling takes a lot of time
On Thu, Nov 10, 2016 at 10:16 AM, Manikandan Selvaganesh
wrote:
> Enabling/disabling quota or removing limits are the ways in which quota.conf
> is regenerated to the later version. It works properly. And as Pranith said,
> both enabling/disabling takes a lot of time to
Enabling/disabling quota or removing limits are the ways in which
quota.conf is regenerated to the later version. It works properly. And as
Pranith said, both enabling/disabling takes a lot of time to crawl(though
now much faster with enhanced quota enable/disable process) which we cannot
suggest
On Thu, Nov 10, 2016 at 2:14 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:
>
>
> On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee
> wrote:
>
>>
>>
>> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
>> pkara...@redhat.com> wrote:
>>
>>> I am trying to
On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee wrote:
>
>
> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> I am trying to understand the criticality of these patches. Raghavendra's
>> patch is crucial because gfapi
On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee wrote:
>
>
> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com> wrote:
>
>> I am trying to understand the criticality of these patches. Raghavendra's
>> patch is crucial because gfapi
On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri
wrote:
> hi,
> The only problem left was EC taking more time. This should affect
> small files a lot more. Best way to solve it is using compound-fops. So for
> now I think going ahead with the release is best.
>
On Thu, Nov 10, 2016 at 1:11 PM, Atin Mukherjee wrote:
>
>
> On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri
> wrote:
>>
>> I am trying to understand the criticality of these patches. Raghavendra's
>> patch is crucial because gfapi workloads(for
On Thu, Nov 10, 2016 at 1:04 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:
> I am trying to understand the criticality of these patches. Raghavendra's
> patch is crucial because gfapi workloads(for samba and qemu) are affected
> severely. I waited for Krutika's patch because VM
I am trying to understand the criticality of these patches. Raghavendra's
patch is crucial because gfapi workloads(for samba and qemu) are affected
severely. I waited for Krutika's patch because VM usecase can lead to disk
corruption on replace-brick. If you could let us know the criticality and
Pranith,
I'd like to see following patches getting in:
http://review.gluster.org/#/c/15722/
http://review.gluster.org/#/c/15714/
http://review.gluster.org/#/c/15792/
On Thu, Nov 10, 2016 at 7:12 AM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:
> hi,
> The only problem left was
24 matches
Mail list logo