Re: [Gluster-devel] [gluster-packaging] Release 4.0: Making it happen! (GlusterD2)

[Kaushal M]

On Thu, Jan 11, 2018 at 1:56 AM, Kaleb S. KEITHLEY  wrote:
> comments inline
>
> On 01/10/2018 02:08 PM, Shyam Ranganathan wrote:
>
> Hi, (GD2 team, packaging team, please read)
>
> Here are some things we need to settle so that we can ship/release GD2
> along with Gluster 4.0 release (considering this is a separate
> repository as of now).
>
> 1) Generating release package (read as RPM for now) to go with Gluster
> 4.0 release
>
> Proposal:
>   - GD2 makes github releases, as in [1]
>
>   - GD2 Releases (tagging etc.) are made in tandem to Gluster releases
> - So, when an beta1/RC0 is tagged for gluster release, this will
> receive a coordinated release (if required) from the GD2 team
> - GD2 team will receive *at-least* a 24h notice on a tentative
> Gluster tagging date/time, to aid the GD2 team to prepare the required
> release tarball in github
>
> This is a no-op. In github creating a tag or a release automatically creates
> the tar source file.

While true, this tarball isn't enough. The GD2 build scripts lookup
versioning from git tags or from a VERSION file (same as glusterfs).
Both of these are not present in the tarball github generates.
The GD2 release script generates tarballs that have everything
required to build a properly versioned GD2.

>
>   - Post a gluster tag being created, and the subsequent release job is
> run for gluster 4.0, the packaging team will be notified about which GD2
> tag to pick up for packaging, with this gluster release
> - IOW, a response to the Jenkins generated packaging job, with the
> GD2 version/tag/release to pick up
>
>   - GD2 will be packaged as a sub-package of the glusterfs package, and
> hence will have appropriate changes to the glusterfs spec file (or other
> variants of packaging as needed), to generate one more package (RPM) to
> post in the respective download location
>
>   - The GD2 sub-package version would be the same as the release version
> that GD2 makes (it will not be the gluster package version, at least for
> now)
>
> IMO it's clearer if the -glusterd2 sub-package has the same version as the
> rest of the glusterfs-* packages.
>

+1. We will follow glusterfs versioning not just for the packages, but
for the source itself.

> The -glusterd2 sub-package's Summary and/or its %description can be used to
> identify the version of GD2.
>
> Emphasis on IMO. It is possible for the -glusterd sub-package to have a
> version that's different than the parent package(s).
>
>   - For now, none of the gluster RPMs would be dependent on the GD2 RPM
> in the downloads, so any user wanting to use GD2 would have to install
> the package specifically and then proceed as needed
>
>   - (thought/concern) Jenkins smoke job (or other jobs) that builds RPMs
> will not build GD2 (as the source is not available) and will continue as
> is (which means there is enough spec file magic here that we can specify
> during release packaging to additionally build GD2)
>
> 2) Generate a quick start or user guide, to aid using GD2 with 4.0
>
> @Kaushal if this is generated earlier (say with beta builds of 4.0
> itself) we could get help from the community to test drive the same and
> provide feedback to improve the guide for users by the release (as
> discussed in the maintainers meeting)
>
> One thing not covered above is what happens when GD2 fixes a high priority
> bug between releases of glusterfs.
>
> Once option is we wait until the next release of glusterfs to include the
> update to GD2.
>
> Or we can respin (rerelease) the glusterfs packages with the updated GD2.
> I.e. glusterfs-4.0.0-1 (containing GD2-1.0.0) -> glusterfs-4.0.0-2
> (containing GD2-1.0.1).
>
> Or we can decide not to make a hard rule and do whatever makes the most
> sense at the time. If the fix is urgent, we respin. If the fix is not urgent
> it waits for the next Gluster release. (From my perspective though I'd
> rather not do respins, I've already got plenty of work doing the regular
> releases.)
>
> The alternative to all of the above is to package GD2 in its own package.
> This entails opening a New Package Request and going through the packaging
> reviews. All in all it's a lot of work. If GD2 source is eventually going to
> be moved into the main glusterfs source though this probably doesn't make
> sense.
>
> --
>
> Kaleb
>
>
>
>
> ___
> packaging mailing list
> packag...@gluster.org
> http://lists.gluster.org/mailman/listinfo/packaging
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [gluster-packaging] Release 4.0: Making it happen! (GlusterD2)

[Kaushal M]

On Thu, Jan 11, 2018 at 12:38 AM, Shyam Ranganathan  wrote:
> Hi, (GD2 team, packaging team, please read)
>
> Here are some things we need to settle so that we can ship/release GD2
> along with Gluster 4.0 release (considering this is a separate
> repository as of now).
>
> 1) Generating release package (read as RPM for now) to go with Gluster
> 4.0 release
>
> Proposal:
>   - GD2 makes github releases, as in [1]
>
>   - GD2 Releases (tagging etc.) are made in tandem to Gluster releases
> - So, when an beta1/RC0 is tagged for gluster release, this will
> receive a coordinated release (if required) from the GD2 team
> - GD2 team will receive *at-least* a 24h notice on a tentative
> Gluster tagging date/time, to aid the GD2 team to prepare the required
> release tarball in github

Sounds good.

>
>   - Post a gluster tag being created, and the subsequent release job is
> run for gluster 4.0, the packaging team will be notified about which GD2
> tag to pick up for packaging, with this gluster release
> - IOW, a response to the Jenkins generated packaging job, with the
> GD2 version/tag/release to pick up
>
>   - GD2 will be packaged as a sub-package of the glusterfs package, and
> hence will have appropriate changes to the glusterfs spec file (or other
> variants of packaging as needed), to generate one more package (RPM) to
> post in the respective download location
>
>   - The GD2 package version would be the same as the release version
> that GD2 makes (it will not be the gluster package version, at least for
> now)

I prefer if GD2 follows gluster versioning. Keeps things simpler.
Anyone packaging will have to just pick the same version of GD2.
We already version our perview releases as v4.0dev.

>
>   - For now, none of the gluster RPMs would be dependent on the GD2 RPM
> in the downloads, so any user wanting to use GD2 would have to install
> the package specifically and then proceed as needed

Yes. The glusterfs-server package will not depend on GD2 right now.
This will be changed later when GD2 becomes the default.

>
>   - (thought/concern) Jenkins smoke job (or other jobs) that builds RPMs
> will not build GD2 (as the source is not available) and will continue as
> is (which means there is enough spec file magic here that we can specify
> during release packaging to additionally build GD2)

The glusterfs spec file can be updated to include building GD2 from
its release tarball. I don't remember exactly but, rpmbuild might have
ways to automatically download sources/dependencies. We can check if
this is true.

>
> 2) Generate a quick start or user guide, to aid using GD2 with 4.0
>
> @Kaushal if this is generated earlier (say with beta builds of 4.0
> itself) we could get help from the community to test drive the same and
> provide feedback to improve the guide for users by the release (as
> discussed in the maintainers meeting).

We will do this.

>
> Thanks,
> Shyam
>
> [1] github GD2 releases: https://github.com/gluster/glusterd2/releases
> ___
> packaging mailing list
> packag...@gluster.org
> http://lists.gluster.org/mailman/listinfo/packaging
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Integration of GPU with glusterfs

[Milind Changire]

bit-rot is another feature that consumes much CPU to calculate the file
content hash


On Thu, Jan 11, 2018 at 11:42 AM, Ashish Pandey  wrote:

> Hi,
>
> We have been thinking of exploiting GPU capabilities to enhance
> performance of glusterfs. We would like to know others thoughts on this.
> In EC, we have been doing CPU intensive computations to encode and decode
> data before writing and reading. This requires a lot of CPU cycles and we
> have
> been observing 100% CPU usage on client side. Data healing will also have
> the same impact as it also needs to do read-decode-encode-write cycle.
> As most of the  modern servers comes with GPU feature, having glusterfs
> GPU ready might give us performance improvements.
> This is not only specific to EC volume, there are other features which
> will require a lot of computations and could use this capability; For
> Example:
> 1 - Encryption/Decryption
> 2 - Compression and de-duplication
> 3 - Hashing
> 4 - Any other? [Please add if you have something in mind]
>
> Before proceeding further we would like to have your inputs on this.
> Do you have any other use case (existing or future) which could perform
> better on GPU?
> Do you think that it is worth to integrate GPU with glusterfs? The effort
> to have this performance gain could be achieved by some other better ways.
> Any input on the way we should implement it.
>
> There is a gihub issue opened for this. Please provide your comment or
> reply to this mail.
>
> A - https://github.com/gluster/glusterfs/issues/388
>
> ---
> Ashish
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Milind
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Integration of GPU with glusterfs

[Ashish Pandey]

Hi, 

We have been thinking of exploiting GPU capabilities to enhance performance of 
glusterfs. We would like to know others thoughts on this. 
In EC, we have been doing CPU intensive computations to encode and decode data 
before writing and reading. This requires a lot of CPU cycles and we have 
been observing 100% CPU usage on client side. Data healing will also have the 
same impact as it also needs to do read-decode-encode-write cycle. 
As most of the modern servers comes with GPU feature, having glusterfs GPU 
ready might give us performance improvements. 
This is not only specific to EC volume, there are other features which will 
require a lot of computations and could use this capability; For Example: 
1 - Encryption/Decryption 
2 - Compression and de-duplication 
3 - Hashing 
4 - Any other? [Please add if you have something in mind] 

Before proceeding further we would like to have your inputs on this. 
Do you have any other use case (existing or future) which could perform better 
on GPU? 
Do you think that it is worth to integrate GPU with glusterfs? The effort to 
have this performance gain could be achieved by some other better ways. 
Any input on the way we should implement it. 

There is a gihub issue opened for this. Please provide your comment or reply to 
this mail. 

A - https://github.com/gluster/glusterfs/issues/388 

--- 
Ashish 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] posix_disk_space_check and internal clients

[Nithya Balachandran]

Hi,

DISK_SPACE_CHECK_AND_GOTO in posix.h allows all calls from internal clients
to bypass the check. But in edge cases, internal clients could write to
files and fill up the brick. Would it be better to not allow some fops like
write in this case for internal clients as well?

Regards,
Nithya
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Release 3.12.5: Scheduled for the 12th of January

[Jiffin Tony Thottan]

Hi,

It's time to prepare the 3.12.5 release, which falls on the 10th of
each month, and hence would be 12-01-2018 this time around.

This mail is to call out the following,

1) Are there any pending *blocker* bugs that need to be tracked for
3.12.5? If so mark them against the provided tracker [1] as blockers
for the release, or at the very least post them as a response to this
mail

2) Pending reviews in the 3.12 dashboard will be part of the release,
*iff* they pass regressions and have the review votes, so use the
dashboard [2] to check on the status of your patches to 3.12 and get
these going

3) I have made checks on what went into 3.10 post 3.12 release and if
these fixes are already included in 3.12 branch, then status on this is 
*green*

as all fixes ported to 3.10, are ported to 3.12 as well.

Thanks,
Jiffin

[1] Release bug tracker:
https://bugzilla.redhat.com/show_bug.cgi?id=glusterfs-3.12.5

[2] 3.12 review dashboard:
https://review.gluster.org/#/projects/glusterfs,dashboards/dashboard:3-12-dashboard 

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Please file a bug if you take a machine offline

[Nigel Babu]

Hello folks,

If you take a machine offline, please file a bug so that the machine can be
debugged and return to the pool.

-- 
nigelb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Recent regression failures

[Nigel Babu]

Hello folks,

We may have been a little too quick to blame Meltdown on the Jenkins
failures yesterday. In any case, we've open a ticket with our provider and
they're looking into the failures. I've looked at the last 90 failures to
get a comprehensive number on the failures.

Total Jobs: 90
Failures: 62
Failure Percentage: 68.89%

I've analyzed the individual failures categorized them as well.

slave28.cloud.gluster.org failure: 9
Geo-replication failures: 12
Fops-during-migration.t: 4
Compilation failures: 3
durability-off.t failures: 7

These alone total to 35 failures. The slave28 failures were due to the
machine running out of disk space. We had a very large binary archived from
an experimental branch build failure. I've cleared that core out and this
is now fixed. The geo-replication failures were due to geo-rep tests
depending on root's .bashrc having the PATH variable modified. This was not
a standard setup and therefore didn't work on many machines. This has now
been fixed. The other 3 were transient failures either limited to a
particular review or a temporary bustage on master. The majority of the
recent failures had more to do with infra than to do with tests.

I'm therefore cautiously moving with the assumption that the impact of KPTI
patch is minimal so far.

-- 
nigelb
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] a link issue maybe introduced in a bug fix " Don't let NFS cache stat after writes"

[Pranith Kumar Karampuri]

On Thu, Jan 11, 2018 at 6:35 AM, Lian, George (NSB - CN/Hangzhou) <
george.l...@nokia-sbell.com> wrote:

> Hi,
>
> >>> In which protocol are you seeing this issue? Fuse/NFS/SMB?
>
> It is fuse, within mountpoint by “mount -t glusterfs  …“ command.
>

Could you let me know the test you did so that I can try to re-create and
see what exactly is going on?
Configuration of the volume and the steps to re-create the issue you are
seeing would be helpful in debugging the issue further.


>
>
> Thanks & Best Regards,
>
> George
>
>
>
> *From:* gluster-devel-boun...@gluster.org [mailto:gluster-devel-bounces@
> gluster.org] *On Behalf Of *Pranith Kumar Karampuri
> *Sent:* Wednesday, January 10, 2018 8:08 PM
> *To:* Lian, George (NSB - CN/Hangzhou) 
> *Cc:* Zhou, Cynthia (NSB - CN/Hangzhou) ;
> Zhong, Hua (NSB - CN/Hangzhou) ; Li, Deqian
> (NSB - CN/Hangzhou) ; Gluster-devel@gluster.org;
> Sun, Ping (NSB - CN/Hangzhou) 
> *Subject:* Re: [Gluster-devel] a link issue maybe introduced in a bug fix
> " Don't let NFS cache stat after writes"
>
>
>
>
>
>
>
> On Wed, Jan 10, 2018 at 11:09 AM, Lian, George (NSB - CN/Hangzhou) <
> george.l...@nokia-sbell.com> wrote:
>
> Hi, Pranith Kumar,
>
>
>
> I has create a bug on Bugzilla https://bugzilla.redhat.com/
> show_bug.cgi?id=1531457
>
> After my investigation for this link issue, I suppose your changes on
> afr-dir-write.c with issue " Don't let NFS cache stat after writes" , your
> fix is like:
>
> --
>
>if (afr_txn_nothing_failed (frame, this)) {
>
> /*if it did pre-op, it will do post-op changing
> ctime*/
>
> if (priv->consistent_metadata &&
>
> afr_needs_changelog_update (local))
>
> afr_zero_fill_stat (local);
>
> local->transaction.unwind (frame, this);
>
> }
>
> In the above fix, it set the ia_nlink to ‘0’ if option
> consistent-metadata is set to “on”.
>
> And hard link a file with which just created will lead to an error, and
> the error is caused in kernel function “vfs_link”:
>
> if (inode->i_nlink == 0 && !(inode->i_state & I_LINKABLE))
>
>  error =  -ENOENT;
>
>
>
> could you please have a check and give some comments here?
>
>
>
> When stat is "zero filled", understanding is that the higher layer
> protocol doesn't send stat value to the kernel and a separate lookup is
> sent by the kernel to get the latest stat value. In which protocol are you
> seeing this issue? Fuse/NFS/SMB?
>
>
>
>
>
> Thanks & Best Regards,
>
> George
>
>
>
>
> --
>
> Pranith
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] a link issue maybe introduced in a bug fix " Don't let NFS cache stat after writes"

[Raghavendra G]

+csaba for fuse. +poornima, if the issue turns out to be an issue in
md-cache caching.

On Wed, Jan 10, 2018 at 5:37 PM, Pranith Kumar Karampuri <
pkara...@redhat.com> wrote:

>
>
> On Wed, Jan 10, 2018 at 11:09 AM, Lian, George (NSB - CN/Hangzhou) <
> george.l...@nokia-sbell.com> wrote:
>
>> Hi, Pranith Kumar,
>>
>>
>>
>> I has create a bug on Bugzilla https://bugzilla.redhat.com/sh
>> ow_bug.cgi?id=1531457
>>
>> After my investigation for this link issue, I suppose your changes on
>> afr-dir-write.c with issue " Don't let NFS cache stat after writes" , your
>> fix is like:
>>
>> --
>>
>>if (afr_txn_nothing_failed (frame, this)) {
>>
>> /*if it did pre-op, it will do post-op changing
>> ctime*/
>>
>> if (priv->consistent_metadata &&
>>
>> afr_needs_changelog_update (local))
>>
>> afr_zero_fill_stat (local);
>>
>> local->transaction.unwind (frame, this);
>>
>> }
>>
>> In the above fix, it set the ia_nlink to ‘0’ if option
>> consistent-metadata is set to “on”.
>>
>> And hard link a file with which just created will lead to an error, and
>> the error is caused in kernel function “vfs_link”:
>>
>> if (inode->i_nlink == 0 && !(inode->i_state & I_LINKABLE))
>>
>>  error =  -ENOENT;
>>
>>
>>
>> could you please have a check and give some comments here?
>>
>
> When stat is "zero filled", understanding is that the higher layer
> protocol doesn't send stat value to the kernel and a separate lookup is
> sent by the kernel to get the latest stat value. In which protocol are you
> seeing this issue? Fuse/NFS/SMB?
>
>
>>
>>
>> Thanks & Best Regards,
>>
>> George
>>
>
>
>
> --
> Pranith
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Raghavendra G
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Exact purpose of network.ping-timeout

[Raghavendra Gowdappa]

+gluster-devel

- Original Message -
> From: "Raghavendra Gowdappa" 
> To: "Omar Kohl" 
> Cc: gluster-us...@gluster.org
> Sent: Wednesday, January 10, 2018 11:47:31 AM
> Subject: Re: [Gluster-users] Exact purpose of network.ping-timeout
> 
> 
> 
> - Original Message -
> > From: "Raghavendra Gowdappa" 
> > To: "Omar Kohl" 
> > Cc: gluster-us...@gluster.org
> > Sent: Wednesday, January 10, 2018 10:56:21 AM
> > Subject: Re: [Gluster-users] Exact purpose of network.ping-timeout
> > 
> > Sorry about the delayed response. Had to dig into the history to answer
> > various "why"s.
> > 
> > - Original Message -
> > > From: "Omar Kohl" 
> > > To: gluster-us...@gluster.org
> > > Sent: Tuesday, December 26, 2017 6:41:48 PM
> > > Subject: [Gluster-users] Exact purpose of network.ping-timeout
> > > 
> > > Hi,
> > > 
> > > I have a question regarding the "ping-timeout" option. I have been
> > > researching its purpose for a few days and it is not completely clear to
> > > me.
> > > Especially that it is apparently strongly encouraged by the Gluster
> > > community not to change or at least decrease this value!
> > > 
> > > Assuming that I set ping-timeout to 10 seconds (instead of the default
> > > 42)
> > > this would mean that if I have a network outage of 11 seconds then
> > > Gluster
> > > internally would have to re-allocate some resources that it freed after
> > > the
> > > 10 seconds, correct? But apart from that there are no negative
> > > implications,
> > > are there? For instance if I'm copying files during the network outage
> > > then
> > > those files will continue copying after those 11 seconds.
> > > 
> > > This means that the only purpose of ping-timeout is to save those extra
> > > resources that are used by "short" network outages. Is that correct?
> > 
> > Basic purpose of ping-timer/heartbeat is to identify an unresponsive brick.
> > Unresponsiveness can be caused due to various reasons like:
> > * A deadlocked server. We no longer see too many instances of deadlocked
> > bricks/server
> > * Slow execution of fops in brick stack. For eg.,
> > - due to lock contention. There have been some efforts to fix the lock
> > contention on brick stack.
> > - bad backend OS/filesystem. Posix health checker was an effort to fix
> > this.
> > - Not enough threads for execution etc
> >   Note that ideally its not the job of ping framework to identify this
> >   scenario and following the same thought process we've shielded the
> >   processing of ping requests on bricks from the costs of execution of
> >   requests to Glusterfs Program.
> > 
> > * Ungraceful shutdown of network connections. For eg.,
> > - hard shutdown of machine/container/VM running the brick
> > - physically pulling out the network cable
> >   Basically all those different scenarios where TCP/IP doesn't get a chance
> >   to inform the other end that it is going down. Note that some of the
> >   scenarios of ungraceful network shutdown can be identified using
> >   TCP_KEEPALIVE and TCP_USERTIMEOUT [1]. However, at the time when
> >   heartbeat
> >   mechanism was introduced in Glusterfs, TCP_KEEPALIVE couldn't identify
> >   all
> >   the ungraceful network shutdown scenarios and TCP_USER_TIMEOUT was yet to
> >   be implemented in Linux kernel. One scenario which TCP_KEEPALIVE could
> 
> s/could/couldn't/
> 
> >   identify was the exact scenario TCP_USER_TIMEOUT aims to solve -
> >   identifying an hard network shutdown when data is in transit. However
> >   there might be other limitations in TCP_KEEPALIVE which we need to test
> >   out before retiring heart beat mechanism in favor of TCP_KEEPALIVE and
> >   TCP_USER_TIMEOUT.
> > 
> > The next interesting question would be why we need to identify an
> > unresponsive brick. Various reasons why we need to do that would be:
> > * To replace/fix any problems the brick might have
> > * Almost all of the cluster translators - DHT, AFR, EC - wait for a
> > response
> > from all of their children - either successful or failure - before sending
> > the response back to application. This means one or more slow/unresponsive
> > brick can increase the latencies of fops/syscalls even though other bricks
> > are responsive and healthy. However there are ongoing efforts to minimize
> > the effect of few slow/unresponsive bricks [2]. I think principles of [2]
> > can applied to DHT and AFR too.
> > 
> > Some recent discussions on the necessity of ping framework in glusterfs can
> > be found at [3].
> > 
> > Having given all the above reasons for the existence of ping framework, its
> > also important that ping-framework shouldn't bring down an otherwise
> > healthy
> > connection (False positives). Reasons are:
> > * As pointed out by Joe Julian in another mail on this thread, each
> > connection carries some state on bricks like locks/open-fds 

[Gluster-devel] Release 4.0: Making it happen! (Protocol changes and wireshark)

[Shyam Ranganathan]

Hi,

As we are introducing a new protocol version, the existing gluster
wireshark plugin [1] needs to be updated.

Further this needs to get released to wireshark users in some fashion,
which looks like a need to follow wireshark roadmap [2] (not sure if
this can be part of a maintenance release, which would possibly be based
on the quantum of changes etc.).

This need not happen with 4.0 branching, but at least has to be
completed before 4.0 release.

@neils once the protocol changes are complete, would this be possible to
complete by you in the next 6 odd weeks by the release (end of Feb)? Or,
if we need volunteers, please give a shout out here.

Shyam

[1] Gluster wireshark plugin:
https://code.wireshark.org/review/gitweb?p=wireshark.git;a=tree;f=epan/dissectors;h=8c8303285a204bdff3b8b80e2811dcd9b7ab6fe0;hb=HEAD

[2] Wireshark roadmap: https://wiki.wireshark.org/Development/Roadmap

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [gluster-packaging] Release 4.0: Making it happen! (GlusterD2)

[Kaleb S. KEITHLEY]

comments inline

On 01/10/2018 02:08 PM, Shyam Ranganathan wrote:
> Hi, (GD2 team, packaging team, please read) Here are some things we
> need to settle so that we can ship/release GD2 along with Gluster 4.0
> release (considering this is a separate repository as of now). 1)
> Generating release package (read as RPM for now) to go with Gluster
> 4.0 release Proposal: - GD2 makes github releases, as in [1] - GD2
> Releases (tagging etc.) are made in tandem to Gluster releases - So,
> when an beta1/RC0 is tagged for gluster release, this will receive a
> coordinated release (if required) from the GD2 team - GD2 team will
> receive *at-least* a 24h notice on a tentative Gluster tagging
> date/time, to aid the GD2 team to prepare the required release tarball
> in github
This is a no-op. In github creating a tag or a release automatically
creates the tar source file.
> - Post a gluster tag being created, and the subsequent release job is
> run for gluster 4.0, the packaging team will be notified about which
> GD2 tag to pick up for packaging, with this gluster release - IOW, a
> response to the Jenkins generated packaging job, with the GD2
> version/tag/release to pick up - GD2 will be packaged as a sub-package
> of the glusterfs package, and hence will have appropriate changes to
> the glusterfs spec file (or other variants of packaging as needed), to
> generate one more package (RPM) to post in the respective download
> location - The GD2 sub-package version would be the same as the
> release version that GD2 makes (it will not be the gluster package
> version, at least for now)
IMO it's clearer if the -glusterd2 sub-package has the same version as
the rest of the glusterfs-* packages.

The -glusterd2 sub-package's Summary and/or its %description can be used
to identify the version of GD2.

Emphasis on IMO. It is possible for the -glusterd sub-package to have a
version that's different than the parent package(s).
> - For now, none of the gluster RPMs would be dependent on the GD2 RPM
> in the downloads, so any user wanting to use GD2 would have to install
> the package specifically and then proceed as needed -
> (thought/concern) Jenkins smoke job (or other jobs) that builds RPMs
> will not build GD2 (as the source is not available) and will continue
> as is (which means there is enough spec file magic here that we can
> specify during release packaging to additionally build GD2) 2)
> Generate a quick start or user guide, to aid using GD2 with 4.0
> @Kaushal if this is generated earlier (say with beta builds of 4.0
> itself) we could get help from the community to test drive the same
> and provide feedback to improve the guide for users by the release (as
> discussed in the maintainers meeting)
One thing not covered above is what happens when GD2 fixes a high
priority bug between releases of glusterfs.

Once option is we wait until the next release of glusterfs to include
the update to GD2.

Or we can respin (rerelease) the glusterfs packages with the updated
GD2. I.e. glusterfs-4.0.0-1 (containing GD2-1.0.0) -> glusterfs-4.0.0-2
(containing GD2-1.0.1).

Or we can decide not to make a hard rule and do whatever makes the most
sense at the time. If the fix is urgent, we respin. If the fix is not
urgent it waits for the next Gluster release. (From my perspective
though I'd rather not do respins, I've already got plenty of work doing
the regular releases.)

The alternative to all of the above is to package GD2 in its own
package. This entails opening a New Package Request and going through
the packaging reviews. All in all it's a lot of work. If GD2 source is
eventually going to be moved into the main glusterfs source though this
probably doesn't make sense.

--

Kaleb



___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Release 4.0: Making it happen! (GlusterD2)

[Shyam Ranganathan]

Hi, (GD2 team, packaging team, please read)

Here are some things we need to settle so that we can ship/release GD2
along with Gluster 4.0 release (considering this is a separate
repository as of now).

1) Generating release package (read as RPM for now) to go with Gluster
4.0 release

Proposal:
  - GD2 makes github releases, as in [1]

  - GD2 Releases (tagging etc.) are made in tandem to Gluster releases
- So, when an beta1/RC0 is tagged for gluster release, this will
receive a coordinated release (if required) from the GD2 team
- GD2 team will receive *at-least* a 24h notice on a tentative
Gluster tagging date/time, to aid the GD2 team to prepare the required
release tarball in github

  - Post a gluster tag being created, and the subsequent release job is
run for gluster 4.0, the packaging team will be notified about which GD2
tag to pick up for packaging, with this gluster release
- IOW, a response to the Jenkins generated packaging job, with the
GD2 version/tag/release to pick up

  - GD2 will be packaged as a sub-package of the glusterfs package, and
hence will have appropriate changes to the glusterfs spec file (or other
variants of packaging as needed), to generate one more package (RPM) to
post in the respective download location

  - The GD2 package version would be the same as the release version
that GD2 makes (it will not be the gluster package version, at least for
now)

  - For now, none of the gluster RPMs would be dependent on the GD2 RPM
in the downloads, so any user wanting to use GD2 would have to install
the package specifically and then proceed as needed

  - (thought/concern) Jenkins smoke job (or other jobs) that builds RPMs
will not build GD2 (as the source is not available) and will continue as
is (which means there is enough spec file magic here that we can specify
during release packaging to additionally build GD2)

2) Generate a quick start or user guide, to aid using GD2 with 4.0

@Kaushal if this is generated earlier (say with beta builds of 4.0
itself) we could get help from the community to test drive the same and
provide feedback to improve the guide for users by the release (as
discussed in the maintainers meeting).

Thanks,
Shyam

[1] github GD2 releases: https://github.com/gluster/glusterd2/releases
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Release 4.0: Making it happen!

[Shyam Ranganathan]

Hi,

4.0 branching date is slated on the 16th of Jan 2018 and release is
slated for the end of Feb (28th), 2018.

We are at the phase when we need to ensure our release scope is correct
and *must* release features are landing. Towards this we need the
following information for all contributors.

1) Features that are making it to the release by branching date

- There are currently 35 open github issues marked as 4.0 milestone [1]
- Need contributors to look at this list and let us know which will meet
the branching date
- Need contributors to let us know which may slip and hence needs a
backport exception to 4.0 branch (post branching).
- Need milestone corrections on features that are not making it to the
4.0 release

NOTE: Slips are accepted if they fall 1-1.5 weeks post branching, not
post that, and called out before branching!

2) Reviews needing priority

- There could be features that are up for review, and considering we
have about 6-7 days before branching, we need a list of these commits,
that you want review attention on.
- This will be added to this [2] dashboard, easing contributor access to
top priority reviews before branching

3) Review help!

- This link [2] contains reviews that need attention, as they are
targeted for 4.0. Request maintainers and contributors to pay close
attention to this list on a daily basis and help out with reviews.

Thanks,
Shyam

[1] github issues marked for 4.0:
https://github.com/gluster/glusterfs/milestone/3

[2] Review focus for features planned to land in 4.0:
https://review.gluster.org/#/q/owner:srangana%2540redhat.com+is:starred

___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Maintainer Meeting minutes - Jan 10th, 2018

[Amar Tumballi]

The first maintainers' meeting of the year 2018 went well, and there were
discussion and participation till the last minute. I hope more maintainers
join regularly to this meeting, and make it easier to take decisions.


BJ Link

   - Bridge: https://bluejeans.com/205933580
   - Download: https://bluejeans.com/s/LgtTV


Attendance

   - [Sorry Note] Misc, Amye, Atin (conflicting meeting), Ravi
   - Amar, Nigel, Shyam, Kaleb, Nithya, Kotresh, Csaba, Xavi, Kaushal,
   Aravinda, Raghavendra G


Agenda

   -

   4.0 ? Are we good to branch?
   -

  GD2 : Not a blocker as it is continuing in another repo
  - [Kaushal] Aravinda’s Volgen is in. Helps with different volume
 types.
 - Should also help to get rebalance and heal commands.
 - Planning to have a release this week.
 - Upstream glusterfs master works with GD2 (or GD2 works with
 master)
 - [Shyam] RC release packaging requirement? What do we need?
 - [kshlm] Need golang on build system. Some more changes in
 Makefile and build scripts. Other than that don’t see much
issues with RPM
 building.
 - Building tarball with all dependencies also may be needed.
 - Tarball will contain all dependencies. Fedora may have issues.
 Have to check with Niels about CentOS.
 - AI: Shyam to start mailthread about this with package
 maintainers.
 - Need a quickstart guide - Current guide
 
.
 Present. Need some more data there. And feedback.
 - [kshlm] provide recovery steps for whole cluster goes down.
 - [Amar] Need a release and quickstart guide on priority.
 - [Shyam] A week after branching is good time
  -

  [Atin] Changes for making GD2 understand options across all the
  xlators are not yet complete. Would that become a blocker for branch out?
  - [Shyam] Is it blocker? Looks like it is not blocker, may be allowed
 to be bug fix post branching. But loosing momentum is a concern.
 - [kshlm] Fine with it as its only GD2 which consumes it.
 - AI: Shyam to mention it in email about 4.0 branching.
  -

  Protocol : Plumbing done, regression failures being debugged. Need
  another week to have it ready. (See https://review.gluster.org/19098.)
  - From today, not after branching
 - AI: check with Wireshark changes need to be done by 4.0 release
 - No need to define futurist fops now.
  -

  CentOS6 support in 4.0?
  - [Kaleb] Concerns with Python/GoLang issues, mostly
 - [Kshlm] gd2 doesn’t build on centos6. may work on epel.
 - [Nigel] We are ready to move to centos7 on regression. No
 dependency on centos6.
 - [Shyam] Is there a concern from centos SIG? [Kaleb] No.
 - This is a community question.
 - AI: Need to be checked with community and any downstream
 concerns for people.
  -

  NetBSD support in 4.0?
  -

  Other features as tracked in the github lane for 4.0 [Shyam]
  - 35 open, 11 closed. Please update.
 - Check the milestone link here
 
 - AI: need to send a mail as not everyone concerned are present.
  -

  Review focus for patches targetted for 4.0 [Shyam]
  - AI: To send a email to start focused reviews.
 - Surely need focused effort here, with priority.
  -

  Kaushal is speaking at FOSDEM and DevConf - 2018 about Gluster-4.0
  GD2.
  - Will reach out for reviews of presentation
  -

   Current failures of centos6 regression failure?
   - [Kaleb] Random failures happening right now
  - [Jdarcy] Can you paste the link? Here
  
  - [Nithya] Is it rebased after ssl revert?
  - [Aravinda & Kotresh] There were failures on geo-rep test cases, and
  now mostly fixed. Thanks to Nigel.
  - [Nithya] Is it timing related? has the spectre & meltdown patches
  gone in ? [Nigel] Yes, they are all updated.
  - [Kaleb] Patch is just about linking libraries (in makefile), but no
  code change. Treat it as showstopper, for branching.
  - [RaghuG] See some ABORT errors [NigelB] All of them were about
  timeout, bumped up the timeout.
  - [Nigel] AI: Can consider changing the provider.
   -

   Upcoming infra changes
   - [Nigel] Background story: to be short, no more funding from current
  provider, and is costlier for the requirement we have.
  - We’re working on moving from a static infra to dynamic test
  infrastructure.
  - We’re also switching providers. Currently evaluating new providers

[Gluster-devel] Side effect of the metldown fix for regression

[Michael Scherer]

Hi,

so it seems that the meltdown fix did slowdown regression testing, as
told to me by Nigel (after Nithya pointed this looked like timing
issue). 

After a quick discussion on irc, we suspect this might be the lack of
pcid for the rackspace hosts.

So the good news is that we have a fix:
 https://twitter.com/berrange/status/950209752486817792


The bad news is that we can only add it to builder in the cage, which
is unfortunate.

A ticket was opened to rackspace by Nigel, and I will watch over it to
have it fixed ASAP.  

In the mean time, I am taking care of fixing it in the cage as a backup
plan, but that might need a reboot of the various builders (and that's
always fun to hit "put that node offline" 40 times 2 times, because
jenkins is hard to automate with our configuration).

-- 
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS



signature.asc
Description: This is a digitally signed message part
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Simulating some kind of "virtual file"

[Amar Tumballi]

Check the files in $mountpoint/.meta/ directory. These are all virtual. And
meta xlator gives a very good idea about how to handle virtual files (and
directories).

-Amar

On Wed, Jan 10, 2018 at 6:36 PM, Xavi Hernandez  wrote:

> Hi David,
>
> On Wed, Jan 10, 2018 at 1:42 PM, David Spisla 
> wrote:
>>
>> *[David Spisla] I tried this:*
>>
>> *char *new_path = malloc(1+len_path-5);*
>>
>> *memcpy(new_path, loc->path, len_path-5);*
>>
>> *new_path[strlen(new_path)] = '\0';*
>>
>> *loc->name = new_path + (len_path - len_name);*
>>
>>
>>
>> First of all, you should always use memory allocation functions from
>> gluster. This includes GF_MALLOC(), gf_strdup(), gf_asprintf() and several
>> other variants. You can look at libglusterfs/src/mem-pool.h to see all
>> available options.
>>
>>
>>
>> The second problem I see is that memcpy() doesn't write a terminating
>> null character, so when you compute strlen() afterwards, it will return
>> invalid length, or even try to access invalid memory, causing a crash.
>>
>>
>>
>> You should do something like this (assuming both loc->path and loc->name
>> are not NULL and skipping many necessary checks):
>>
>>
>>
>> len_path = strlen(loc->path);
>>
>> len_name = strlen(loc->name);
>>
>> new_path = GF_MALLOC(len_path - 4, gf_common_mt_char);
>>
>> memcpy(new_path, loc->path, len_path - 5);
>>
>> new_path[len_path - 5] = 0;
>>
>> loc->name = new_path + len_path - len_name;
>>
>>
>>
>> This should work fine.
>>
>>
>>
>> Xavi
>>
>> *[David Spisla] Yes, this worls fine. Thank you ****. By the way, is
>> there a way inside gluster xlator to get access to xattr or attr of a file.
>> In the lookup function there is only the struct loc, but I am missing there
>> the files gfid. It seems to be null always. I could use syncop_getxattr()
>> with the parameter loc, but the gfid is missing. Can I get the gfid if I
>> have only loc->path and loc-> name? It is like a conversion from files path
>> to files gfid.*
>>
>
> One of the main purposes of the 'lookup' fop is to resolve a given path to
> an existing gfid, so you won't find any gfid in the lookup request (unless
> it's a revalidate request). You need to look at the response (cbk) of the
> lookup to get the real gfid. If the request succeeds, you can find the gfid
> in buf->ia_gfid of the lookup callback.
>
> Other fops that receive a loc_t structure are normally called after a
> successful lookup, so loc->gfid and/or loc->inode->gfid should be set
> (unfortunately there isn't an homogeneous management of loc_t structures by
> xlators, so not always both fields are set).
>
> You can also request additional xattrs in the lookup request by adding
> them to the xdata dictionary. Their values will be returned in the xdata
> argument of the lookup callback.
>
> Xavi
>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Amar Tumballi (amarts)
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Simulating some kind of "virtual file"

[Xavi Hernandez]

Hi David,

On Wed, Jan 10, 2018 at 1:42 PM, David Spisla 
wrote:
>
> *[David Spisla] I tried this:*
>
> *char *new_path = malloc(1+len_path-5);*
>
> *memcpy(new_path, loc->path, len_path-5);*
>
> *new_path[strlen(new_path)] = '\0';*
>
> *loc->name = new_path + (len_path - len_name);*
>
>
>
> First of all, you should always use memory allocation functions from
> gluster. This includes GF_MALLOC(), gf_strdup(), gf_asprintf() and several
> other variants. You can look at libglusterfs/src/mem-pool.h to see all
> available options.
>
>
>
> The second problem I see is that memcpy() doesn't write a terminating null
> character, so when you compute strlen() afterwards, it will return invalid
> length, or even try to access invalid memory, causing a crash.
>
>
>
> You should do something like this (assuming both loc->path and loc->name
> are not NULL and skipping many necessary checks):
>
>
>
> len_path = strlen(loc->path);
>
> len_name = strlen(loc->name);
>
> new_path = GF_MALLOC(len_path - 4, gf_common_mt_char);
>
> memcpy(new_path, loc->path, len_path - 5);
>
> new_path[len_path - 5] = 0;
>
> loc->name = new_path + len_path - len_name;
>
>
>
> This should work fine.
>
>
>
> Xavi
>
> *[David Spisla] Yes, this worls fine. Thank you ****. By the way, is
> there a way inside gluster xlator to get access to xattr or attr of a file.
> In the lookup function there is only the struct loc, but I am missing there
> the files gfid. It seems to be null always. I could use syncop_getxattr()
> with the parameter loc, but the gfid is missing. Can I get the gfid if I
> have only loc->path and loc-> name? It is like a conversion from files path
> to files gfid.*
>

One of the main purposes of the 'lookup' fop is to resolve a given path to
an existing gfid, so you won't find any gfid in the lookup request (unless
it's a revalidate request). You need to look at the response (cbk) of the
lookup to get the real gfid. If the request succeeds, you can find the gfid
in buf->ia_gfid of the lookup callback.

Other fops that receive a loc_t structure are normally called after a
successful lookup, so loc->gfid and/or loc->inode->gfid should be set
(unfortunately there isn't an homogeneous management of loc_t structures by
xlators, so not always both fields are set).

You can also request additional xattrs in the lookup request by adding them
to the xdata dictionary. Their values will be returned in the xdata
argument of the lookup callback.

Xavi
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] a link issue maybe introduced in a bug fix " Don't let NFS cache stat after writes"

[Pranith Kumar Karampuri]

On Wed, Jan 10, 2018 at 11:09 AM, Lian, George (NSB - CN/Hangzhou) <
george.l...@nokia-sbell.com> wrote:

> Hi, Pranith Kumar,
>
>
>
> I has create a bug on Bugzilla https://bugzilla.redhat.com/
> show_bug.cgi?id=1531457
>
> After my investigation for this link issue, I suppose your changes on
> afr-dir-write.c with issue " Don't let NFS cache stat after writes" , your
> fix is like:
>
> --
>
>if (afr_txn_nothing_failed (frame, this)) {
>
> /*if it did pre-op, it will do post-op changing
> ctime*/
>
> if (priv->consistent_metadata &&
>
> afr_needs_changelog_update (local))
>
> afr_zero_fill_stat (local);
>
> local->transaction.unwind (frame, this);
>
> }
>
> In the above fix, it set the ia_nlink to ‘0’ if option consistent-metadata
> is set to “on”.
>
> And hard link a file with which just created will lead to an error, and
> the error is caused in kernel function “vfs_link”:
>
> if (inode->i_nlink == 0 && !(inode->i_state & I_LINKABLE))
>
>  error =  -ENOENT;
>
>
>
> could you please have a check and give some comments here?
>

When stat is "zero filled", understanding is that the higher layer protocol
doesn't send stat value to the kernel and a separate lookup is sent by the
kernel to get the latest stat value. In which protocol are you seeing this
issue? Fuse/NFS/SMB?


>
>
> Thanks & Best Regards,
>
> George
>



-- 
Pranith
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel