Re: [Gluster-devel] Clang-Formatter for GlusterFS.
On Mon, Sep 17, 2018 at 10:00 AM, Ravishankar N
wrote:
>
> On 09/13/2018 03:34 PM, Niels de Vos wrote:
>
>> On Thu, Sep 13, 2018 at 02:25:22PM +0530, Ravishankar N wrote:
>> ...
>>
>>> What rules does clang impose on function/argument wrapping and
>>> alignment? I
>>> somehow found the new code wrapping to be random and highly unreadable.
>>> An
>>> example of 'before and after' the clang format patches went in:
>>> https://paste.fedoraproject.org/paste/dC~aRCzYgliqucGYIzxPrQ Wondering
>>> if
>>> this is just me or is it some problem of spurious clang fixes.
>>>
>> I agree that this example looks pretty ugly. Looking at random changes
>> to the code where I am most active does not show this awkward
>> formatting.
>>
>
> So one of my recent patches is failing smoke and clang-format is insisting
> [https://build.gluster.org/job/clang-format/22/console] on wrapping
> function arguments in an unsightly manner. Should I resend my patch with
> this new style of wrapping ?
>
>
I would say yes! We will get better, by changing options of clang-format
once we get better options there. But for now, just following the option
suggested by clang-format job is good IMO.
-Amar
> Regards,
> Ravi
>
>
>
>
>> However, I was expecting to see enforcing of the
>> single-line-if-statements like this (and while/for/.. loops):
>>
>> if (need_to_do_it) {
>> do_it();
>> }
>>
>> instead of
>>
>> if (need_to_do_it)
>> do_it();
>>
>> At least the conversion did not take care of this. But, maybe I'm wrong
>> as I can not find the discussion in https://bugzilla.redhat.com/1564149
>> about this. Does someone remember what was decided in the end?
>>
>> Thanks,
>> Niels
>>
>
>
--
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Cloudsync with AFR
Hi Anuradha, To enable the c-time (consistent time) feature. Please enable following two options. gluster vol set utime on gluster vol set ctime on Thanks, Kotresh HR On Fri, Sep 14, 2018 at 12:18 PM, Rafi Kavungal Chundattu Parambil < rkavu...@redhat.com> wrote: > Hi Anuradha, > > We have an xlator to provide consistent time across replica set. You can > enable this xlator to get the consistent mtime,atime, ctime. > > > Regards > Rafi KC > > - Original Message - > From: "Anuradha Talur" > To: gluster-devel@gluster.org > Cc: ama...@redhat.com, "Ram Ankireddypalle" , > "Sachin Pandit" > Sent: Thursday, September 13, 2018 7:19:26 AM > Subject: [Gluster-devel] Cloudsync with AFR > > > > Hi, > > We recently started testing cloudsync xlator on a replica volume. > And we have noticed a few issues. We would like some advice on how to > proceed with them. > > > > 1) As we know, when stubbing a file cloudsync uses mtime of files to > decide whether a file should be truncated or not. > > If the mtime provided as part of the setfattr operation is lesser than the > current mtime of the file on brick, stubbing isn't completed. > > This works fine in a plain distribute volume. B ut i n case of a replica > volume, the mtime could be different for the files on each of the replica > brick. > > > During our testing we came across the following scenario for a replica 3 > volume with 3 bricks: > > We performed `setfattr -n "trusted.glusterfs.csou.complete" -v m1 file1` > from our gluster mount to stub the files. > It so happened that on brick1 this operation succeeded and truncated file1 > as it should have. But on brick2 and brick3, mtime found on file1 > was greater than m1, leading to failure there. > > From AFR's perspective this operation failed as a whole because quorum > could not be met. But on the brick where this setxattr succeeded, truncate > was already performed. So now we have one of the replica bricks out of sync > and AFR has no awareness of this. This file needs to be rolled back to its > state before the > > > setfattr. > > Ideally, it appears that we should add intelligence in AFR to handle this. > How do you suggest we do that? > > > The case is also applicable to EC volumes of course. > > 2) Given that cloudsync depends on mtime to make the decision of > truncating, how do we ensure that we don't end up in this situation again? > > Thanks, > Anuradha > ***Legal Disclaimer*** > "This communication may contain confidential and privileged material for > the > sole use of the intended recipient. Any unauthorized review, use or > distribution > by others is strictly prohibited. If you have received the message by > mistake, > please advise the sender by reply email and delete the message. Thank > you." > ** > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > https://lists.gluster.org/mailman/listinfo/gluster-devel > -- Thanks and Regards, Kotresh H R ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Clang-Formatter for GlusterFS.
On 09/13/2018 03:34 PM, Niels de Vos wrote:
On Thu, Sep 13, 2018 at 02:25:22PM +0530, Ravishankar N wrote:
...
What rules does clang impose on function/argument wrapping and alignment? I
somehow found the new code wrapping to be random and highly unreadable. An
example of 'before and after' the clang format patches went in:
https://paste.fedoraproject.org/paste/dC~aRCzYgliqucGYIzxPrQ Wondering if
this is just me or is it some problem of spurious clang fixes.
I agree that this example looks pretty ugly. Looking at random changes
to the code where I am most active does not show this awkward
formatting.
So one of my recent patches is failing smoke and clang-format is
insisting [https://build.gluster.org/job/clang-format/22/console] on
wrapping function arguments in an unsightly manner. Should I resend my
patch with this new style of wrapping ?
Regards,
Ravi
However, I was expecting to see enforcing of the
single-line-if-statements like this (and while/for/.. loops):
if (need_to_do_it) {
do_it();
}
instead of
if (need_to_do_it)
do_it();
At least the conversion did not take care of this. But, maybe I'm wrong
as I can not find the discussion in https://bugzilla.redhat.com/1564149
about this. Does someone remember what was decided in the end?
Thanks,
Niels
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Weekly Untriaged Bugs
[...truncated 6 lines...] https://bugzilla.redhat.com/1620116 / cli: Gluster cli doesn't show an error message when creating a disperse volume using IP addresses https://bugzilla.redhat.com/1626085 / fuse: "glusterfs --process-name fuse" crashes and leads to "Transport endpoint is not connected" https://bugzilla.redhat.com/1628269 / geo-replication: [geo-rep]: _GMaster: changelogs could not be processed completely - moving on... https://bugzilla.redhat.com/1626043 / geo-replication: Geo-replication setup fails, glusterd crahes when replication is setup https://bugzilla.redhat.com/1628219 / libgfapi: High memory consumption depending on volume bricks count https://bugzilla.redhat.com/1629079 / packaging: Error because glusterfs RPM package uses the most recent libglusterfs0 instead of the one with the same version https://bugzilla.redhat.com/1620377 / project-infrastructure: Coverity scan setup for gluster-block and related projects https://bugzilla.redhat.com/1625501 / project-infrastructure: gd2 smoke tests fail with cannot create directory ‘/var/lib/glusterd’: Permission denied https://bugzilla.redhat.com/1623596 / project-infrastructure: Git plugin might be suffering from memory leak https://bugzilla.redhat.com/1626453 / project-infrastructure: glusterd2-containers nightly job failing https://bugzilla.redhat.com/1623452 / project-infrastructure: Mock does not exit cleanly when a job is aborted https://bugzilla.redhat.com/1628458 / project-infrastructure: Request for a bastion SSH host on Rackspace https://bugzilla.redhat.com/1627624 / project-infrastructure: Run gd2-smoke only after smoke passes https://bugzilla.redhat.com/1620358 / project-infrastructure: smoke job failures https://bugzilla.redhat.com/1622814 / rpc: kvm lock problem https://bugzilla.redhat.com/1623618 / rpc: mgmt/glusterd: ABRT from Fedora (CentOS) in glusterd_rpcsvc_notify() https://bugzilla.redhat.com/1626610 / snapshot: [USS]: Change gf_log to gf_msg https://bugzilla.redhat.com/1627060 / trash-xlator: ./tests/features/trash.t test case failing on s390x https://bugzilla.redhat.com/1620580 / unclassified: Deleted a volume and created a new volume with similar but not the same name. The kubernetes pod still keeps on running and doesn't crash. Still possible to write to gluster mount [...truncated 2 lines...] build.log Description: Binary data ___ Gluster-devel mailing list Gluster-devel@gluster.org https://lists.gluster.org/mailman/listinfo/gluster-devel
