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

[Hetz Ben Hamo]

There are 3 issues with adding GPU and adding code to glusterFS:

1. Cost: Since you cannot stick any GTX card inside your server, you'll be
forced to buy a $2K+ card for that. That could be an issue if the GlusterFS
is made out of old/cheap servers and the company/institution doesn't have
money for that.
2. You cannot insert any non GTX (or AMD's VEGA) cards to a 1U server.
3. Even if you find a solution for the 2 issues mentioned above, the code
will need to support both OpenCL and CUDA.

Instead of GPU, how about thinking about some cheap DSP PCIe solution?

On Fri, Jan 12, 2018 at 2:30 PM, Jim Kinney  wrote:

>
>
> On January 11, 2018 10:58:28 PM EST, Lindsay Mathieson <
> lindsay.mathie...@gmail.com> wrote:
> >On 12/01/2018 3:14 AM, Darrell Budic wrote:
> >> It would also add physical resource requirements to future client
> >> deploys, requiring more than 1U for the server (most likely), and I’m
> >
> >> not likely to want to do this if I’m trying to optimize for client
> >> density, especially with the cost of GPUs today.
> >
> >Nvidia has banned their GPU's being used in Data Centers now to, I
> >imagine they are planning to add a licensing fee.
>
> Nvidia banned only the lower cost, home user versions of their GPU line
> from datacenters.
> >
> >--
> >Lindsay Mathieson
> >
> >___
> >Gluster-users mailing list
> >gluster-us...@gluster.org
> >http://lists.gluster.org/mailman/listinfo/gluster-users
>
> --
> Sent from my Android device with K-9 Mail. All tyopes are thumb related
> and reflect authenticity.
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-users
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Jim Kinney]

On January 11, 2018 10:58:28 PM EST, Lindsay Mathieson 
 wrote:
>On 12/01/2018 3:14 AM, Darrell Budic wrote:
>> It would also add physical resource requirements to future client 
>> deploys, requiring more than 1U for the server (most likely), and I’m
>
>> not likely to want to do this if I’m trying to optimize for client 
>> density, especially with the cost of GPUs today.
>
>Nvidia has banned their GPU's being used in Data Centers now to, I 
>imagine they are planning to add a licensing fee.

Nvidia banned only the lower cost, home user versions of their GPU line from 
datacenters. 
>
>-- 
>Lindsay Mathieson
>
>___
>Gluster-users mailing list
>gluster-us...@gluster.org
>http://lists.gluster.org/mailman/listinfo/gluster-users

-- 
Sent from my Android device with K-9 Mail. All tyopes are thumb related and 
reflect authenticity.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Determine if a file is open in a cluster

[Ram Ankireddypalle]

Thanks Vijay/Raghavendra. We will try this.

Thanks and Regards,
Ram

From: raghavendra...@gmail.com [mailto:raghavendra...@gmail.com] On Behalf Of 
Raghavendra G
Sent: Thursday, January 11, 2018 11:20 PM
To: Vijay Bellur
Cc: Ram Ankireddypalle; gluster-devel@gluster.org
Subject: Re: [Gluster-devel] Determine if a file is open in a cluster

Another simple test in code would be to check whether inode->fd_list is empty 
as fd_list represents list of all fds opened on that inode.

On Fri, Jan 12, 2018 at 4:38 AM, Vijay Bellur 
> wrote:
Hi Ram,

Do you want to check this from within a translator? If so, you can look for 
GLUSTERFS_OPEN_FD_COUNT in xlators like dht, afr, ec etc. where they check for 
open file descriptors in various FOPs.

Regards,
Vijay

On Thu, Jan 11, 2018 at 10:40 AM, Ram Ankireddypalle 
> wrote:
Hi,
   Is it possible to find out within a cluster if a file is currently open 
by any of the clients/self-heal daemon or any other daemon’s within a cluster. 
Please point to the sample code in any of the Xlator which does such a check.

Thanks and Regards,
Ram
***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
http://lists.gluster.org/mailman/listinfo/gluster-devel


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



--
Raghavendra G
***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
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Coverity covscan for 2018-01-12-cf37aa99 (master branch)

[staticanalysis]

GlusterFS Coverity covscan results are available from
http://download.gluster.org/pub/gluster/glusterfs/static-analysis/master/glusterfs-coverity/2018-01-12-cf37aa99
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] [GD2] New release - GlusterD2 v4.0dev-10

[Kaushal M]

We have a new GD2 release!!

This has been a while coming. The last release happened around the
time of the Gluster summit, and we have been working hard the last 2
months.

There have been a lot of changes, most of them aimed at getting GD2 in
shape for release.  We also have new commands and CLIs implemented for
you to try.

The release is available from [1].
RPMs are available from the COPR repository at [2]. The RPMs require
the nightly builds of GlusterFS master, currently only available for
EL [3].
There is a quick start guide available at [4].

We're working on implementing more commands and we hope to have some
more preview releases before GlusterFS-4.0 lands.

Thanks!
GD2 developers

[1]: https://github.com/gluster/glusterd2/releases/tag/v4.0dev-10
[2]: https://copr.fedorainfracloud.org/coprs/kshlm/glusterd2/
[3]: http://artifacts.ci.centos.org/gluster/nightly/master.repo
[4]: 
https://github.com/gluster/glusterd2/blob/v4.0dev-10/doc/quick-start-user-guide.md
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

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

[Niels de Vos]

On Wed, Jan 10, 2018 at 03:36:55PM -0500, Shyam Ranganathan wrote:
> 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.

Adding the new bits to the Wireshark dissector is pretty straight
forward. Once the protocol changes have been done, it would be good to
have a few .pcap files captured that can be used for developing and
testing the changes. This can even be done in steps, as soon as one
chunk of the protocol is finalized, a patch to upstream Wireshark can be
sent already. We can improve it incrementally that way, also making it
easier for multiple contributors to work on it.

I can probably do some of the initial work, but would like assistance
from others with testing and possibly improving certain parts. If
someone can provide tcpdumps with updated protocol changes, that would
be most welcome! Capture the dumps like this:

  # tcpdump -i any -w /var/tmp/gluster-40-${proto_change}.pcap -s 0 tcp and not 
port 22
  ... exercise the protocol bit that changed, include connection setup
  ... press CTRL+C once done
  # gzip /var/tmp/gluster-40-${proto_change}.pcap
  ... Wireshark can read .pcap.gz without manual decompressing

Attach the .pcap.gz to the GitHub issue for the protocol change and
email gluster-devel@ once it is available so that a developer can start
working on the Wireshark change.

Thanks,
Niels


> 
> 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)

[Niels de Vos]

On Thu, Jan 11, 2018 at 12:14:20PM -0500, Kaleb S. KEITHLEY wrote:
> On 01/11/2018 11:34 AM, Shyam Ranganathan wrote:
> >>>
> >>> 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.)
> > 
> > I would think we follow what we need to do for the gluster package (and
> > its sub-packages) as it stands now. If there is an important enough fix
> > (critical/security etc.) that requires a one-off build (ie. not a
> > maintenance release or a regular release) we respin the whole thing
> > (which is more work).
> > 
> > I think if it is a GD2 specific fix then just re-spinning that
> > sub-package makes more sense and possibly less work.
> 
> RPM (and Debian) packaging is an all or nothing proposition. There is no
> respinning just the -glusterd2 sub-package.
> 
> > I am going to leave the decision of re-spinning the whole thing or just
> > the GD2 package to the packaging folks, but state that re-spin rules do
> > not change, IOW, if something is critical enough we re-spin as we do today.
> 
> I think my real question was what should happen when GD2 discovers/fixes
> a severe bug between the regular release dates.
> 
> If we take the decision that it needs to be released immediately (with
> packages built), do we:
> 
>   a) make a whole new glusterfs Release with just the GD2 fix. I.e.
> glusterfs-4.0.4-1.rpm  ->  glusterfs-4.0.5-1.rpm. IOW we bump the _V_ in
> the NVR? (This implies tagging the glusterfs source with the new tag at
> the same location as the previous tag.)
> 
> or
> 
>   b) "respin" the existing glusterfs release, also with just the GD2
> fix. I.e. glusterfs-4.0.4-1.rpm  ->  glusterfs-4.0.4-2.rpm. IOW we bump
> the _R_ in the NVR?
> 
> 
> Obviously (or is it?) if we find serious bugs in core gluster and GD2
> that we want to release we can update both and that would be a new
> Version (_V_ in the NVR).

I think it will be really painful to maintain a .spec that has the
current (already very complex) glusterfs bits, and the new GD2
components. Packaging Golang is quite different from anything written in
C, and will make the mixed language .spec most ugly. (Remember the
difficulties with the gluster-swift/ufo bundling?)

If GD2 evolves at a different rate than glusterfs, it seems better to
package is separately. This will make it possible to update it more
often if needed. Maintaining the packages will also be simpler. Because
GD2 is supposed to be less intimate with the glusterfs internals, there
may come a point where the GD2 version does not need to match the
glusterfs version anymore.

Keeping the same major versions would be good, and that makes it easy to
set the correct Requires: in the .spec files.

Packaging GD2 by itself for Fedora should not be a problem. There are
several package maintainers in the Gluster Community and all can
propose, review and approve new packages. If two packages is the right
technical approach, we should work to make that happen.

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

Re: [Gluster-devel] [Gluster-infra] Recent regression failures

[Kotresh Hiremath Ravishankar]

Nigel,

Could you give a machine where geo-rep is failing even with bashrc fix to
debug ?

Thanks,
Kotresh HR

On Fri, Jan 12, 2018 at 3:54 PM, Amar Tumballi  wrote:

> Can we have a separate test case to validate for all the basic necessity
> for whole test suite to pass? That way the very first run will report an
> error in the setup and we can fix it faster, instead of waiting for the
> failure which is a setup issue after 3-4hrs ?
>
> -Amar
>
> On Fri, Jan 12, 2018 at 3:47 PM, Atin Mukherjee 
> wrote:
>
>>
>>
>> On Thu, Jan 11, 2018 at 10:15 AM, Nigel Babu  wrote:
>>
>>> 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.
>>>
>>
>> While Nigel tells me that the infra related problems for geo-rep tests
>> are already fixed, I see a similar failure pops up through
>> https://build.gluster.org/job/centos6-regression/8356/console .
>>
>> @Kotresh - Could you check if this is something different?
>>
>>
>>> 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
>>>
>>
>>
>> ___
>> Gluster-infra mailing list
>> gluster-in...@gluster.org
>> http://lists.gluster.org/mailman/listinfo/gluster-infra
>>
>
>
>
> --
> Amar Tumballi (amarts)
>



-- 
Thanks and Regards,
Kotresh H R
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-infra] Recent regression failures

[Amar Tumballi]

Can we have a separate test case to validate for all the basic necessity
for whole test suite to pass? That way the very first run will report an
error in the setup and we can fix it faster, instead of waiting for the
failure which is a setup issue after 3-4hrs ?

-Amar

On Fri, Jan 12, 2018 at 3:47 PM, Atin Mukherjee  wrote:

>
>
> On Thu, Jan 11, 2018 at 10:15 AM, Nigel Babu  wrote:
>
>> 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.
>>
>
> While Nigel tells me that the infra related problems for geo-rep tests are
> already fixed, I see a similar failure pops up through
> https://build.gluster.org/job/centos6-regression/8356/console .
>
> @Kotresh - Could you check if this is something different?
>
>
>> 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
>>
>
>
> ___
> Gluster-infra mailing list
> gluster-in...@gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-infra
>



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

Re: [Gluster-devel] Recent regression failures

[Atin Mukherjee]

On Thu, Jan 11, 2018 at 10:15 AM, Nigel Babu  wrote:

> 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.
>

While Nigel tells me that the infra related problems for geo-rep tests are
already fixed, I see a similar failure pops up through
https://build.gluster.org/job/centos6-regression/8356/console .

@Kotresh - Could you check if this is something different?


> 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
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel