Re: [Gluster-devel] Improve stability between SMB/CTDB and Gluster (together with Samba Core Developer)

[Poornima Gurusiddaiah]

Hi,

We would be definitely interested in this. Thank you for contacting us. For
the starter we can have an online conference. Please suggest few possible
date and times for the week(preferably between IST 7.00AM - 9.PM)?
Adding Anoop and Gunther who are also the main contributors to the
Gluster-Samba integration.

Thanks,
Poornima



On Thu, May 9, 2019 at 7:43 PM David Spisla  wrote:

> Dear Gluster Community,
> at the moment we are improving the stability of SMB/CTDB and Gluster. For
> this purpose we are working together with an advanced SAMBA Core Developer.
> He did some debugging but needs more information about Gluster Core
> Behaviour.
>
> *Would any of the Gluster Developer wants to have a online conference with
> him and me?*
>
> I would organize everything. In my opinion this is a good chance to
> improve stability of Glusterfs and this is at the moment one of the major
> issues in the Community.
>
> Regards
> David Spisla
> ___
>
> Community Meeting Calendar:
>
> APAC Schedule -
> Every 2nd and 4th Tuesday at 11:30 AM IST
> Bridge: https://bluejeans.com/836554017
>
> NA/EMEA Schedule -
> Every 1st and 3rd Tuesday at 01:00 PM EDT
> Bridge: https://bluejeans.com/486278655
>
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
>
>
___

Community Meeting Calendar:

APAC Schedule -
Every 2nd and 4th Tuesday at 11:30 AM IST
Bridge: https://bluejeans.com/836554017

NA/EMEA Schedule -
Every 1st and 3rd Tuesday at 01:00 PM EDT
Bridge: https://bluejeans.com/486278655

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

Re: [Gluster-devel] [Gluster-users] Prioritise local bricks for IO?

[Poornima Gurusiddaiah]

This feature is not under active development as it was not used widely.
AFAIK its not supported feature.
+Nithya +Raghavendra for further clarifications.

Regards,
Poornima

On Wed, Mar 27, 2019 at 12:33 PM Lucian  wrote:

> Oh, that's just what the doctor ordered!
> Hope it works, thanks
>
> On 27 March 2019 03:15:57 GMT, Vlad Kopylov  wrote:
>>
>> I don't remember if it still in works
>> NUFA
>>
>> https://github.com/gluster/glusterfs-specs/blob/master/done/Features/nufa.md
>>
>> v
>>
>> On Tue, Mar 26, 2019 at 7:27 AM Nux!  wrote:
>>
>>> Hello,
>>>
>>> I'm trying to set up a distributed backup storage (no replicas), but I'd
>>> like to prioritise the local bricks for any IO done on the volume.
>>> This will be a backup stor, so in other words, I'd like the files to be
>>> written locally if there is space, so as to save the NICs for other traffic.
>>>
>>> Anyone knows how this might be achievable, if at all?
>>>
>>> --
>>> Sent from the Delta quadrant using Borg technology!
>>>
>>> Nux!
>>> www.nux.ro
>>> ___
>>> Gluster-users mailing list
>>> gluster-us...@gluster.org
>>> https://lists.gluster.org/mailman/listinfo/gluster-users
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] Version uplift query

[Poornima Gurusiddaiah]

On Wed, Feb 27, 2019, 11:52 PM Ingo Fischer  wrote:

> Hi Amar,
>
> sorry to jump into this thread with an connected question.
>
> When installing via "apt-get" and so using debian packages and also
> systemd to start/stop glusterd is the online upgrade process from
> 3.x/4.x to 5.x still needed as described at
> https://docs.gluster.org/en/latest/Upgrade-Guide/upgrade_to_4.1/ ?
>
> Especially because there is manual killall and such for processes
> handled by systemd in my case. Or is there an other upgrade guide or
> recommendations for use on ubuntu?
>
> Would systemctl stop glusterd, then using apt-get update with changes
> sources and a reboot be enough?
>

I think you would still need to kill the process manually, AFAIK systemd
only stops glusterd not the other Gluster processes like
glusterfsd(bricks), heal process etc. Reboot of system is not required, if
that's what you meant by reboot. Also you need follow all the other steps
mentioned, for the cluster to work smoothly after upgrade. Especially the
steps to perform heal are important.

Regards,
Poornima


> Ingo
>
> Am 27.02.19 um 16:11 schrieb Amar Tumballi Suryanarayan:
> > GlusterD2 is not yet called out for standalone deployments.
> >
> > You can happily update to glusterfs-5.x (recommend you to wait for
> > glusterfs-5.4 which is already tagged, and waiting for packages to be
> > built).
> >
> > Regards,
> > Amar
> >
> > On Wed, Feb 27, 2019 at 4:46 PM ABHISHEK PALIWAL
> > mailto:abhishpali...@gmail.com>> wrote:
> >
> > Hi,
> >
> > Could  you please update on this and also let us know what is
> > GlusterD2 (as it is under development in 5.0 release), so it is ok
> > to uplift to 5.0?
> >
> > Regards,
> > Abhishek
> >
> > On Tue, Feb 26, 2019 at 5:47 PM ABHISHEK PALIWAL
> > mailto:abhishpali...@gmail.com>> wrote:
> >
> > Hi,
> >
> > Currently we are using Glusterfs 3.7.6 and thinking to switch on
> > Glusterfs 4.1 or 5.0, when I see there are too much code changes
> > between these version, could you please let us know, is there
> > any compatibility issue when we uplift any of the new mentioned
> > version?
> >
> > Regards
> > Abhishek
> >
> >
> >
> > --
> >
> >
> >
> >
> > Regards
> > Abhishek Paliwal
> > ___
> > Gluster-users mailing list
> > gluster-us...@gluster.org 
> > https://lists.gluster.org/mailman/listinfo/gluster-users
> >
> >
> >
> > --
> > Amar Tumballi (amarts)
> >
> > ___
> > Gluster-users mailing list
> > gluster-us...@gluster.org
> > https://lists.gluster.org/mailman/listinfo/gluster-users
> >
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-users
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] I/O performance

[Poornima Gurusiddaiah]

Thank You for all the detailed explanation. If its the disk saturating, if
we run some of the above mentioned tests(with multithreads) on plain xfs,
we should hit the saturation right. Will try out some tests, this is
interesting.

Thanks,
Poornima

On Wed, Feb 6, 2019 at 12:27 PM Xavi Hernandez 
wrote:

> On Wed, Feb 6, 2019 at 7:00 AM Poornima Gurusiddaiah 
> wrote:
>
>>
>>
>> On Tue, Feb 5, 2019, 10:53 PM Xavi Hernandez > wrote:
>>
>>> On Fri, Feb 1, 2019 at 1:51 PM Xavi Hernandez 
>>> wrote:
>>>
>>>> On Fri, Feb 1, 2019 at 1:25 PM Poornima Gurusiddaiah <
>>>> pguru...@redhat.com> wrote:
>>>>
>>>>> Can the threads be categorised to do certain kinds of fops?
>>>>>
>>>>
>>>> Could be, but creating multiple thread groups for different tasks is
>>>> generally bad because many times you end up with lots of idle threads which
>>>> waste resources and could increase contention. I think we should only
>>>> differentiate threads if it's absolutely necessary.
>>>>
>>>>
>>>>> Read/write affinitise to certain set of threads, the other metadata
>>>>> fops to other set of threads. So we limit the read/write threads and not
>>>>> the metadata threads? Also if aio is enabled in the backend the threads
>>>>> will not be blocked on disk IO right?
>>>>>
>>>>
>>>> If we don't block the thread but we don't prevent more requests to go
>>>> to the disk, then we'll probably have the same problem. Anyway, I'll try to
>>>> run some tests with AIO to see if anything changes.
>>>>
>>>
>>> I've run some simple tests with AIO enabled and results are not good. A
>>> simple dd takes >25% more time. Multiple parallel dd take 35% more time to
>>> complete.
>>>
>>
>>
>> Thank you. That is strange! Had few questions, what tests are you running
>> for measuring the io-threads performance(not particularly aoi)? is it dd
>> from multiple clients?
>>
>
> Yes, it's a bit strange. What I see is that many threads from the thread
> pool are active but using very little CPU. I also see an AIO thread for
> each brick, but its CPU usage is not big either. Wait time is always 0 (I
> think this is a side effect of AIO activity). However system load grows
> very high. I've seen around 50, while on the normal test without AIO it's
> stays around 20-25.
>
> Right now I'm running the tests on a single machine (no real network
> communication) using an NVMe disk as storage. I use a single mount point.
> The tests I'm running are these:
>
>- Single dd, 128 GiB, blocks of 1MiB
>- 16 parallel dd, 8 GiB per dd, blocks of 1MiB
>- fio in sequential write mode, direct I/O, blocks of 128k, 16
>threads, 8GiB per file
>- fio in sequential read mode, direct I/O, blocks of 128k, 16 threads,
>8GiB per file
>- fio in random write mode, direct I/O, blocks of 128k, 16 threads,
>8GiB per file
>- fio in random read mode, direct I/O, blocks of 128k, 16 threads,
>8GiB per file
>- smallfile create, 16 threads, 256 files per thread, 32 MiB per file
>(with one brick down, for the following test)
>- self-heal of an entire brick (from the previous smallfile test)
>- pgbench init phase with scale 100
>
> I run all these tests for a replica 3 volume and a disperse 4+2 volume.
>
> Xavi
>
>
>> Regards,
>> Poornima
>>
>>
>>> Xavi
>>>
>>>
>>>> All this is based on the assumption that large number of parallel read
>>>>> writes make the disk perf bad but not the large number of dentry and
>>>>> metadata ops. Is that true?
>>>>>
>>>>
>>>> It depends. If metadata is not cached, it's as bad as a read or write
>>>> since it requires a disk access (a clear example of this is the bad
>>>> performance of 'ls' in cold cache, which is basically metadata reads). In
>>>> fact, cached data reads are also very fast, and data writes could go to the
>>>> cache and be updated later in background, so I think the important point is
>>>> if things are cached or not, instead of if they are data or metadata. Since
>>>> we don't have this information from the user side, it's hard to tell what's
>>>> better. My opinion is that we shouldn't differentiate requests of
>>>> data/metadata. If metadata requests happen to be faster, then that thread
>>>> will be able to handle other requests immediate

Re: [Gluster-devel] I/O performance

[Poornima Gurusiddaiah]

On Tue, Feb 5, 2019, 10:53 PM Xavi Hernandez  On Fri, Feb 1, 2019 at 1:51 PM Xavi Hernandez 
> wrote:
>
>> On Fri, Feb 1, 2019 at 1:25 PM Poornima Gurusiddaiah 
>> wrote:
>>
>>> Can the threads be categorised to do certain kinds of fops?
>>>
>>
>> Could be, but creating multiple thread groups for different tasks is
>> generally bad because many times you end up with lots of idle threads which
>> waste resources and could increase contention. I think we should only
>> differentiate threads if it's absolutely necessary.
>>
>>
>>> Read/write affinitise to certain set of threads, the other metadata fops
>>> to other set of threads. So we limit the read/write threads and not the
>>> metadata threads? Also if aio is enabled in the backend the threads will
>>> not be blocked on disk IO right?
>>>
>>
>> If we don't block the thread but we don't prevent more requests to go to
>> the disk, then we'll probably have the same problem. Anyway, I'll try to
>> run some tests with AIO to see if anything changes.
>>
>
> I've run some simple tests with AIO enabled and results are not good. A
> simple dd takes >25% more time. Multiple parallel dd take 35% more time to
> complete.
>


Thank you. That is strange! Had few questions, what tests are you running
for measuring the io-threads performance(not particularly aoi)? is it dd
from multiple clients?

Regards,
Poornima


> Xavi
>
>
>> All this is based on the assumption that large number of parallel read
>>> writes make the disk perf bad but not the large number of dentry and
>>> metadata ops. Is that true?
>>>
>>
>> It depends. If metadata is not cached, it's as bad as a read or write
>> since it requires a disk access (a clear example of this is the bad
>> performance of 'ls' in cold cache, which is basically metadata reads). In
>> fact, cached data reads are also very fast, and data writes could go to the
>> cache and be updated later in background, so I think the important point is
>> if things are cached or not, instead of if they are data or metadata. Since
>> we don't have this information from the user side, it's hard to tell what's
>> better. My opinion is that we shouldn't differentiate requests of
>> data/metadata. If metadata requests happen to be faster, then that thread
>> will be able to handle other requests immediately, which seems good enough.
>>
>> However there's one thing that I would do. I would differentiate reads
>> (data or metadata) from writes. Normally writes come from cached
>> information that is flushed to disk at some point, so this normally happens
>> in the background. But reads tend to be in foreground, meaning that someone
>> (user or application) is waiting for it. So I would give preference to
>> reads over writes. To do so effectively, we need to not saturate the
>> backend, otherwise when we need to send a read, it will still need to wait
>> for all pending requests to complete. If disks are not saturated, we can
>> have the answer to the read quite fast, and then continue processing the
>> remaining writes.
>>
>> Anyway, I may be wrong, since all these things depend on too many
>> factors. I haven't done any specific tests about this. It's more like a
>> brainstorming. As soon as I can I would like to experiment with this and
>> get some empirical data.
>>
>> Xavi
>>
>>
>>> Thanks,
>>> Poornima
>>>
>>>
>>> On Fri, Feb 1, 2019, 5:34 PM Emmanuel Dreyfus >>
>>>> On Thu, Jan 31, 2019 at 10:53:48PM -0800, Vijay Bellur wrote:
>>>> > Perhaps we could throttle both aspects - number of I/O requests per
>>>> disk
>>>>
>>>> While there it would be nice to detect and report  a disk with lower
>>>> than
>>>> peer performance: that happen sometimes when a disk is dying, and last
>>>> time I was hit by that performance problem, I had a hard time finding
>>>> the culprit.
>>>>
>>>> --
>>>> Emmanuel Dreyfus
>>>> m...@netbsd.org
>>>> ___
>>>> 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

Re: [Gluster-devel] I/O performance

[Poornima Gurusiddaiah]

Can the threads be categorised to do certain kinds of fops? Read/write
affinitise to certain set of threads, the other metadata fops to other set
of threads. So we limit the read/write threads and not the metadata
threads? Also if aio is enabled in the backend the threads will not be
blocked on disk IO right?
All this is based on the assumption that large number of parallel read
writes make the disk perf bad but not the large number of dentry and
metadata ops. Is that true?

Thanks,
Poornima


On Fri, Feb 1, 2019, 5:34 PM Emmanuel Dreyfus  On Thu, Jan 31, 2019 at 10:53:48PM -0800, Vijay Bellur wrote:
> > Perhaps we could throttle both aspects - number of I/O requests per disk
>
> While there it would be nice to detect and report  a disk with lower than
> peer performance: that happen sometimes when a disk is dying, and last
> time I was hit by that performance problem, I had a hard time finding
> the culprit.
>
> --
> Emmanuel Dreyfus
> m...@netbsd.org
> ___
> 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

Re: [Gluster-devel] too many failures on mpx-restart-crash.t on master branch

[Poornima Gurusiddaiah]

Yeah, but Pranith mentioned that the issue is seen even without the iobuf
patch, so the test may fail even after fixing the thread count? Hence
reducing the volume count as suggested may be a better option.

Regards,
Poornima

On Thu, Dec 20, 2018 at 2:41 PM Amar Tumballi  wrote:

> Considering, we have the effort to reduce the threads in progress, should
> we mark it as known issue till we get the other reduced threads patch
> merged?
>
> -Amar
>
> On Thu, Dec 20, 2018 at 2:38 PM Poornima Gurusiddaiah 
> wrote:
>
>> So, this failure is related to patch [1] iobuf. Thanks to Pranith for
>> identifying this. This patch increases the memory consumption in the brick
>> mux use case(**) and causes oom kill. But it is not the problem with the
>> patch itself. The only way to rightly fix it is to fix the issue [2]. That
>> said we cannot wait until this issue is fixed, the possible work arounds
>> are:
>> - Reduce the volume creation count in test case mpx-restart-crash.t
>> (temporarily until [2] is fixed)
>> - Increase the resources(RAM to 4G?) on the regression system
>> - Revert the patch until [2] is completely fixed
>>
>> Root Cause:
>> Without the iobuf patch [1], we had a pre allocated pool of min size
>> 12.5MB(which can grow), in many cases this entire size may not be
>> completely used. Hence we moved to per thread mem pool for iobuf as well.
>> With this we expect the memory consumption of the processes to go down, and
>> it did go down.After creating 20 volumes on the system, the free -m output:
>> With this patch:
>>totalusedfree  shared
>> buff/cache   available
>> Mem:   37892198   290 2491300
>> 968
>> Swap:  3071   0 3071
>>
>> Without this patch:
>>totalusedfree  shared
>> buff/cache   available
>> Mem:   37892280 115 488
>> 1393 647
>> Swap:  3071   0   3071
>> This output can vary based on system state, workload etc. This is not
>> indicative of the exact amount of memory reduction, but of the fact that
>> the memory usage is reduced.
>>
>> But, with brick mux the scenario is different. Since we use per thread
>> mem pool for iobuf in patch [1], the memory consumption due to iobuf
>> increases if the threads increases. In the current brick mux
>> implementation, for 20 volumes(in the mpx-restart-crash test), the number
>> of threads is 1439. And the allocated iobufs(or any other per thread mem
>> pool memory) doesn't get freed until 30s(garbage collection time) of
>> issuing free(eg: iobuf_put). As a result of this the memory consumption of
>> the process appears to increase for brick mux. Reducing the number of
>> threads to <100 [2] will solve this issue. To prove this theory, if we add
>> 30sec delay between each volume create in mpx-restart-crash, the mem
>> consumption is:
>>
>> With this patch after adding 30s delay between create volume:
>>totalused   free  shared  buff/cache
>> available
>> Mem:   37891344  947 4881497
>> 1606
>> Swap:  3071   03071
>>
>> With this patch:
>> totalusedfree  shared
>> buff/cache   available
>> Mem:   37891710 840 235
>> 12381494
>> Swap:  3071   0   3071
>>
>> Without this patch:
>>totalusedfree  shared
>> buff/cache   available
>> Mem:   37891413  969 3551406
>> 1668
>> Swap:  3071   03071
>>
>> Regards,
>> Poornima
>>
>> [1] https://review.gluster.org/#/c/glusterfs/+/20362/
>> [2] https://github.com/gluster/glusterfs/issues/475
>>
>> On Thu, Dec 20, 2018 at 10:28 AM Amar Tumballi 
>> wrote:
>>
>>> Since yesterday at least 10+ patches have failed regression on 
>>> ./tests/bugs/core/bug-1432542-mpx-restart-crash.t
>>>
>>>
>>> Help to debug them soon would be appreciated.
>>>
>>>
>>> Regards,
>>>
>>> Amar
>>>
>>>
>>> --
>>> Amar Tumballi (amarts)
>>> ___
>>> Gluster-devel mailing list
>>> Gluster-devel@gluster.org
>>> https://lists.gluster.org/mailman/listinfo/gluster-devel
>>
>>
>
> --
> Amar Tumballi (amarts)
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
https://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] too many failures on mpx-restart-crash.t on master branch

[Poornima Gurusiddaiah]

So, this failure is related to patch [1] iobuf. Thanks to Pranith for
identifying this. This patch increases the memory consumption in the brick
mux use case(**) and causes oom kill. But it is not the problem with the
patch itself. The only way to rightly fix it is to fix the issue [2]. That
said we cannot wait until this issue is fixed, the possible work arounds
are:
- Reduce the volume creation count in test case mpx-restart-crash.t
(temporarily until [2] is fixed)
- Increase the resources(RAM to 4G?) on the regression system
- Revert the patch until [2] is completely fixed

Root Cause:
Without the iobuf patch [1], we had a pre allocated pool of min size
12.5MB(which can grow), in many cases this entire size may not be
completely used. Hence we moved to per thread mem pool for iobuf as well.
With this we expect the memory consumption of the processes to go down, and
it did go down.After creating 20 volumes on the system, the free -m output:
With this patch:
   totalusedfree  shared  buff/cache
available
Mem:   37892198   290 2491300
968
Swap:  3071   0 3071

Without this patch:
   totalusedfree  shared  buff/cache
available
Mem:   37892280 115 4881393
647
Swap:  3071   0   3071
This output can vary based on system state, workload etc. This is not
indicative of the exact amount of memory reduction, but of the fact that
the memory usage is reduced.

But, with brick mux the scenario is different. Since we use per thread mem
pool for iobuf in patch [1], the memory consumption due to iobuf increases
if the threads increases. In the current brick mux implementation, for 20
volumes(in the mpx-restart-crash test), the number of threads is 1439. And
the allocated iobufs(or any other per thread mem pool memory) doesn't get
freed until 30s(garbage collection time) of issuing free(eg: iobuf_put). As
a result of this the memory consumption of the process appears to increase
for brick mux. Reducing the number of threads to <100 [2] will solve this
issue. To prove this theory, if we add 30sec delay between each volume
create in mpx-restart-crash, the mem consumption is:

With this patch after adding 30s delay between create volume:
   totalused   free  shared  buff/cache
available
Mem:   37891344  947 48814971606
Swap:  3071   03071

With this patch:
totalusedfree  shared  buff/cache
available
Mem:   37891710 840 2351238
1494
Swap:  3071   0   3071

Without this patch:
   totalusedfree  shared  buff/cache
available
Mem:   37891413  969 35514061668
Swap:  3071   03071

Regards,
Poornima

[1] https://review.gluster.org/#/c/glusterfs/+/20362/
[2] https://github.com/gluster/glusterfs/issues/475

On Thu, Dec 20, 2018 at 10:28 AM Amar Tumballi  wrote:

> Since yesterday at least 10+ patches have failed regression on 
> ./tests/bugs/core/bug-1432542-mpx-restart-crash.t
>
>
> Help to debug them soon would be appreciated.
>
>
> Regards,
>
> Amar
>
>
> --
> Amar Tumballi (amarts)
> ___
> 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

Re: [Gluster-devel] ./rfc.sh not pushing patch to gerrit

[Poornima Gurusiddaiah]

Even I encountered the same. If you have clang version less than 6, it
exits. Upgrading clang version fixed it.

Regards,
Poornima

On Fri, Oct 5, 2018, 9:58 AM Sachidananda URS  wrote:

>
>
> On Fri, Oct 5, 2018 at 9:45 AM, Raghavendra Gowdappa 
> wrote:
>
>>
>>
>> On Fri, Oct 5, 2018 at 9:34 AM Raghavendra Gowdappa 
>> wrote:
>>
>>>
>>>
>>> On Fri, Oct 5, 2018 at 9:11 AM Kaushal M  wrote:
>>>
 On Fri, Oct 5, 2018 at 9:05 AM Raghavendra Gowdappa <
 rgowd...@redhat.com> wrote:
 >
 >
 >
 > On Fri, Oct 5, 2018 at 8:53 AM Amar Tumballi 
 wrote:
 >>
 >> Can you try below diff in your rfc, and let me know if it works?
 >
 >
 > No. it didn't. I see the same error.
 >  [rgowdapp@rgowdapp glusterfs]$ ./rfc.sh
 > + rebase_changes
 > + GIT_EDITOR=./rfc.sh
 > + git rebase -i origin/master
 > [detached HEAD e50667e] cluster/dht: clang-format dht-common.c
 >  1 file changed, 10674 insertions(+), 11166 deletions(-)
 >  rewrite xlators/cluster/dht/src/dht-common.c (88%)
 > [detached HEAD 0734847] cluster/dht: fixes to unlinking invalid
 linkto file
 >  1 file changed, 1 insertion(+), 1 deletion(-)
 > [detached HEAD 7aeba07] rfc.sh: test - DO NOT MERGE
 >  1 file changed, 8 insertions(+), 3 deletions(-)
 > Successfully rebased and updated refs/heads/1635145.
 > + check_backport
 > + moveon=N
 > + '[' master = master ']'
 > + return
 > + assert_diverge
 > + git diff origin/master..HEAD
 > + grep -q .
 > ++ git log -n1 --format=%b
 > ++ grep -ow -E
 '([fF][iI][xX][eE][sS]|[uU][pP][dD][aA][tT][eE][sS])(:)?[[:space:]]+(gluster\/glusterfs)?(bz)?#[[:digit:]]+'
 > ++ awk -F '#' '{print $2}'
 > + reference=1635145
 > + '[' -z 1635145 ']'
 > ++ clang-format --version
 > + clang_format='LLVM (http://llvm.org/):
 >   LLVM version 3.4.2
 >   Optimized build.
 >   Built Dec  7 2015 (09:37:36).
 >   Default target: x86_64-redhat-linux-gnu
 >   Host CPU: x86-64'

 This is a pretty old version of clang. Maybe this is the problem?

>>>
>>> Yes. That's what I suspected too. Trying to get repos for the upgrade.
>>>
>>
>> But, what's surprising is that script exits.
>>
>
> What is the return code of clang-format? If it is non-zero then script
> will silently exit because that is what
> it is told to do.
>
> `#!/bin/sh -e' means exit on error.
>
> -sac
>
> ___
> 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

[Gluster-devel] Status update : Brick Mux threads reduction

[Poornima Gurusiddaiah]

Hi,

For each brick, we create atleast 20+ threads, hence in a brick mux use
case, where we load multiple bricks in the same process, there will 100s of
threads resulting in perf issues, memory usage increase.

IO-threads :  Make it global, to the process, and ref count the resource.
patch [1], has failures in brick mux regression, likey not related to the
patch, need to get it passed.

Posix- threads : Janitor, Helper, Fsyncer, instead of using one thread per
task, use synctask framework instead. In the future use thread pool in
patch [2]. Patches are posted[1], fixing some regression failures.

Posix, bitrot aio-thread : This thread cannot be replaced to just use
synctask/thread pool as there cannot be a delay in recieving notifications
and acting on it. Hence, create a global aio event receiver thread for the
process. This is WIP and is not yet posted upstream.

Threads in changelog/bitrot xlator Mohit posted a patch where default
xlator does not need to start a thread if xlator is not enabled
https://review.gluster.org/#/c/glusterfs/+/21304/ (it can save 6 thread per
brick in default option)

Pending: Create a build of these patches, run perf tests with these patches
and analyze the same.


[1] https://review.gluster.org/#/c/glusterfs/+/20761/
[2] https://review.gluster.org/#/c/glusterfs/+/20636/

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

[Gluster-devel] Wireshark dissectors for Gluster 4.0

[Poornima Gurusiddaiah]

Hi,

Here is the patch for dissecting Gluster 4.0 protocol in wireshark [1]. The
initial tests for fops seem to be working. Request you all to add missing
fops, fix/report any issues in decoding.

[1] https://code.wireshark.org/review/#/c/28871

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

Re: [Gluster-devel] [Gluster-infra] bug-1432542-mpx-restart-crash.t failing

[Poornima Gurusiddaiah]

On Tue, Jul 10, 2018, 9:30 AM Amar Tumballi  wrote:

>
>
> On Mon, Jul 9, 2018 at 8:10 PM, Nithya Balachandran 
> wrote:
>
>> We discussed reducing the number of volumes in the maintainers'
>> meeting.Should we still go ahead and do that?
>>
>>
>>
> It would still be a good exercise, IMO. Reducing it to 50-60 volumes from
> 120 now.
>
AFAIK, the test case only creates 20 volumes with 6 bricks and hence 120
bricks served from one brick process. This results in 1000+ threads and 14g
VIRT 4-5g RES.

Regards,
Poornima


>
>> On 9 July 2018 at 15:45, Xavi Hernandez  wrote:
>>
>>> On Mon, Jul 9, 2018 at 11:14 AM Karthik Subrahmanya 
>>> wrote:
>>>
>>>> Hi Deepshikha,
>>>>
>>>> Are you looking into this failure? I can still see this happening for
>>>> all the regression runs.
>>>>
>>>
>>> I've executed the failing script on my laptop and all tests finish
>>> relatively fast. What seems to take time is the final cleanup. I can see
>>> 'semanage' taking some CPU during destruction of volumes. The test required
>>> 350 seconds to finish successfully.
>>>
>>> Not sure what caused the cleanup time to increase, but I've created a
>>> bug [1] to track this and a patch [2] to give more time to this test. This
>>> should allow all blocked regressions to complete successfully.
>>>
>>> Xavi
>>>
>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1599250
>>> [2] https://review.gluster.org/20482
>>>
>>>
>>>> Thanks & Regards,
>>>> Karthik
>>>>
>>>> On Sun, Jul 8, 2018 at 7:18 AM Atin Mukherjee 
>>>> wrote:
>>>>
>>>>>
>>>>> https://build.gluster.org/job/regression-test-with-multiplex/794/display/redirect
>>>>> has the same test failing. Is the reason of the failure different given
>>>>> this is on jenkins?
>>>>>
>>>>> On Sat, 7 Jul 2018 at 19:12, Deepshikha Khandelwal <
>>>>> dkhan...@redhat.com> wrote:
>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> The issue[1] has been resolved. Now the softserve instance will be
>>>>>> having 2GB RAM i.e. same as that of the Jenkins builder's sizing
>>>>>> configurations.
>>>>>>
>>>>>> [1] https://github.com/gluster/softserve/issues/40
>>>>>>
>>>>>> Thanks,
>>>>>> Deepshikha Khandelwal
>>>>>>
>>>>>> On Fri, Jul 6, 2018 at 6:14 PM, Karthik Subrahmanya <
>>>>>> ksubr...@redhat.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> > On Fri 6 Jul, 2018, 5:18 PM Deepshikha Khandelwal, <
>>>>>> dkhan...@redhat.com>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> Hi Poornima/Karthik,
>>>>>> >>
>>>>>> >> We've looked into the memory error that this softserve instance
>>>>>> have
>>>>>> >> showed up. These machine instances have 1GB RAM which is not in the
>>>>>> >> case with the Jenkins builder. It's 2GB RAM there.
>>>>>> >>
>>>>>> >> We've created the issue [1] and will solve it sooner.
>>>>>> >
>>>>>> > Great. Thanks for the update.
>>>>>> >>
>>>>>> >>
>>>>>> >> Sorry for the inconvenience.
>>>>>> >>
>>>>>> >> [1] https://github.com/gluster/softserve/issues/40
>>>>>> >>
>>>>>> >> Thanks,
>>>>>> >> Deepshikha Khandelwal
>>>>>> >>
>>>>>> >> On Fri, Jul 6, 2018 at 3:44 PM, Karthik Subrahmanya <
>>>>>> ksubr...@redhat.com>
>>>>>> >> wrote:
>>>>>> >> > Thanks Poornima for the analysis.
>>>>>> >> > Can someone work on fixing this please?
>>>>>> >> >
>>>>>> >> > ~Karthik
>>>>>> >> >
>>>>>> >> > On Fri, Jul 6, 2018 at 3:17 PM Poornima Gurusiddaiah
>>>>>> >> > 
>>>>>> >> > wrote:
>>>>>> >> >>
>>>>>> >> >>

Re: [Gluster-devel] [Gluster-infra] bug-1432542-mpx-restart-crash.t failing

[Poornima Gurusiddaiah]

On Mon, Jul 9, 2018 at 8:10 PM, Nithya Balachandran 
wrote:

> We discussed reducing the number of volumes in the maintainers'
> meeting.Should we still go ahead and do that?
>

I m not sure about exactly what was discussed. But reducing the number of
volumes may defeat the purpose of the test, as the bug it is fixing is
reproducible only with more number of volumes. I think Jeff will be able to
tell how much is more. I think we can move this to centos CI brick mux
regression job, if it runs on machines with higher RAM?

Regards,
Poornima



>
>
> On 9 July 2018 at 15:45, Xavi Hernandez  wrote:
>
>> On Mon, Jul 9, 2018 at 11:14 AM Karthik Subrahmanya 
>> wrote:
>>
>>> Hi Deepshikha,
>>>
>>> Are you looking into this failure? I can still see this happening for
>>> all the regression runs.
>>>
>>
>> I've executed the failing script on my laptop and all tests finish
>> relatively fast. What seems to take time is the final cleanup. I can see
>> 'semanage' taking some CPU during destruction of volumes. The test required
>> 350 seconds to finish successfully.
>>
>> Not sure what caused the cleanup time to increase, but I've created a bug
>> [1] to track this and a patch [2] to give more time to this test. This
>> should allow all blocked regressions to complete successfully.
>>
>> Xavi
>>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1599250
>> [2] https://review.gluster.org/20482
>>
>>
>>> Thanks & Regards,
>>> Karthik
>>>
>>> On Sun, Jul 8, 2018 at 7:18 AM Atin Mukherjee 
>>> wrote:
>>>
>>>> https://build.gluster.org/job/regression-test-with-multiplex
>>>> /794/display/redirect has the same test failing. Is the reason of the
>>>> failure different given this is on jenkins?
>>>>
>>>> On Sat, 7 Jul 2018 at 19:12, Deepshikha Khandelwal 
>>>> wrote:
>>>>
>>>>> Hi folks,
>>>>>
>>>>> The issue[1] has been resolved. Now the softserve instance will be
>>>>> having 2GB RAM i.e. same as that of the Jenkins builder's sizing
>>>>> configurations.
>>>>>
>>>>> [1] https://github.com/gluster/softserve/issues/40
>>>>>
>>>>> Thanks,
>>>>> Deepshikha Khandelwal
>>>>>
>>>>> On Fri, Jul 6, 2018 at 6:14 PM, Karthik Subrahmanya <
>>>>> ksubr...@redhat.com> wrote:
>>>>> >
>>>>> >
>>>>> > On Fri 6 Jul, 2018, 5:18 PM Deepshikha Khandelwal, <
>>>>> dkhan...@redhat.com>
>>>>> > wrote:
>>>>> >>
>>>>> >> Hi Poornima/Karthik,
>>>>> >>
>>>>> >> We've looked into the memory error that this softserve instance have
>>>>> >> showed up. These machine instances have 1GB RAM which is not in the
>>>>> >> case with the Jenkins builder. It's 2GB RAM there.
>>>>> >>
>>>>> >> We've created the issue [1] and will solve it sooner.
>>>>> >
>>>>> > Great. Thanks for the update.
>>>>> >>
>>>>> >>
>>>>> >> Sorry for the inconvenience.
>>>>> >>
>>>>> >> [1] https://github.com/gluster/softserve/issues/40
>>>>> >>
>>>>> >> Thanks,
>>>>> >> Deepshikha Khandelwal
>>>>> >>
>>>>> >> On Fri, Jul 6, 2018 at 3:44 PM, Karthik Subrahmanya <
>>>>> ksubr...@redhat.com>
>>>>> >> wrote:
>>>>> >> > Thanks Poornima for the analysis.
>>>>> >> > Can someone work on fixing this please?
>>>>> >> >
>>>>> >> > ~Karthik
>>>>> >> >
>>>>> >> > On Fri, Jul 6, 2018 at 3:17 PM Poornima Gurusiddaiah
>>>>> >> > 
>>>>> >> > wrote:
>>>>> >> >>
>>>>> >> >> The same test case is failing for my patch as well [1]. I
>>>>> requested for
>>>>> >> >> a
>>>>> >> >> regression system and tried to reproduce it.
>>>>> >> >> From my analysis, the brick process (mutiplexed) is consuming a
>>>>> lot of
>>>>> >> >> memory, and is being OO

Re: [Gluster-devel] bug-1432542-mpx-restart-crash.t failing

[Poornima Gurusiddaiah]

The same test case is failing for my patch as well [1]. I requested for a
regression system and tried to reproduce it.
>From my analysis, the brick process (mutiplexed) is consuming a lot of
memory, and is being OOM killed. The regression has 1GB ram and the process
is consuming more than 1GB. 1GB for 120 bricks is acceptable considering
there is 1000 threads in that brick process.
Ways to fix:
- Increase the regression system RAM size OR
- Decrease the number of volumes in the test case.

But what is strange is why the test passes sometimes for some patches.
There could be some bug/? in memory consumption.

Regards,
Poornima


On Fri, Jul 6, 2018 at 2:11 PM, Karthik Subrahmanya 
wrote:

> Hi,
>
> $subject is failing on centos regression for most of the patches with
> timeout error.
>
> 07:32:34 
> 
> 07:32:34 [07:33:05] Running tests in file ./tests/bugs/core/bug-1432542-
> mpx-restart-crash.t
> 07:32:34 Timeout set is 300, default 200
> 07:37:34 ./tests/bugs/core/bug-1432542-mpx-restart-crash.t timed out
> after 300 seconds
> 07:37:34 ./tests/bugs/core/bug-1432542-mpx-restart-crash.t: bad status 124
> 07:37:34
> 07:37:34*
> 07:37:34*   REGRESSION FAILED   *
> 07:37:34* Retrying failed tests in case *
> 07:37:34* we got some spurious failures *
> 07:37:34*
> 07:37:34
> 07:42:34 ./tests/bugs/core/bug-1432542-mpx-restart-crash.t timed out
> after 300 seconds
> 07:42:34 End of test ./tests/bugs/core/bug-1432542-mpx-restart-crash.t
> 07:42:34 
> 
>
> Can anyone take a look?
>
> Thanks,
> Karthik
>
>
>
> ___
> 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

Re: [Gluster-devel] Regression failing on tests/bugs/core/bug-1432542-mpx-restart-crash.t

[Poornima Gurusiddaiah]

On Fri, Jun 29, 2018, 5:54 PM Mohit Agrawal  wrote:

> Hi Poornima,
>
> It seems the test case(tests/bugs/core/bug-1432542-mpx-restart-crash.t) is
> crashing because in quota xlator rpc-cleanup code is not perfectly handled
> in brick multiplexing scenario. Though I did not see this issue from a long
> time after done some changes in quota xlator code but now it seems on your
> patch it is consistently reproducible.
>
>For this build to test your code you can mark it as a bad test and try
> to run a regression.I will check how we can resolve the same.
>
I have done that already, and all the regression tests pass if I mark this
one bad. So it's only this the regression is blocked on. Is it possible to
fix it in the near future? Or mark the test bad until then?

Thanks,
Poornima

>
> Regards
> Mohit Agrawal
> ___
> 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

[Gluster-devel] Regression failing on tests/bugs/core/bug-1432542-mpx-restart-crash.t

[Poornima Gurusiddaiah]

Hi,

The regression is failing consistently for patch [1] but never on local
setup. But, it has failed for many other patches as well [2]. Sometimes it
generates core. Its crashing because the lookup is issued after the fini()
is called on the xlators. This crash seems unrelated to the patch it is
failing on. Anyone else has seen similar crash?

#0  0x7f218b1447dc in quota_lookup (frame=0x7f21682480f8,
this=0x7f21487ebd10,
loc=0x7f208b5428d0, xattr_req=0x0) at quota.c:1663
#1  0x7f218af2022b in io_stats_lookup (frame=0x7f2168247fc8,
this=0x7f21487ed580, loc=0x7f208b5428d0, xdata=0x0) at io-stats.c:2784
#2  0x7f219eebf87a in default_rmdir (frame=0x7f2168247fc8,
this=0x7f21487ef210,
loc=0x7f208b5428d0, flags=0, xdata=0x7f21487ee5c0) at defaults.c:2728
#3  0x7f219ee3bd4e in syncop_lookup (subvol=0x7f21487ef210,
loc=0x7f208b5428d0,
iatt=0x7f208b542830, parent=0x0, xdata_in=0x0, xdata_out=0x0) at
syncop.c:1260
#4  0x7f218aa9c562 in server_first_lookup (this=0x7f218c032b40,
client=0x7f216822ce00, reply=0x7f2168207fa8) at server-handshake.c:382
#5  0x7f218aa9e0cd in server_setvolume (req=0x7f21684087c8)
at server-handshake.c:886

(gdb) p this->private
$1 = (void *) 0x0
(gdb) p this->name
$2 = 0x7f21487e9ec0 "patchy-vol02-quota"
(gdb) p *this
$3 = {name = 0x7f21487e9ec0 "patchy-vol02-quota",
  type = 0x7f21487eba90 "features/quota", instance_name = 0x0,
...
  pass_through_fops = 0x7f219f0ee7c0 <_default_fops>, cleanup_starting = 1,
  call_cleanup = 1}
(gdb) p this->local_pool
$4 = (struct mem_pool *) 0x0


[1] https://review.gluster.org/#/c/20362/
[2]
https://fstat.gluster.org/failure/209?state=2_date=2018-05-25_date=2018-06-29=all


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

Re: [Gluster-devel] Disabling use of anonymous fds in open-behind

[Poornima Gurusiddaiah]

On Wed, Jun 13, 2018, 5:22 AM Vijay Bellur  wrote:

>
>
> On Mon, Jun 11, 2018 at 7:44 PM, Raghavendra Gowdappa  > wrote:
>
>> All,
>>
>> This is an option in open-behind, which lets fuse native mounts to use
>> anonymous fds. The reasoning being since anonymous fds are stateless,
>> overhead of open is avoided and hence better performance. However, bugs
>> filed [1][2] seemed to indicate contrary results.
>>
>> Also, using anonymous fds affects other xlators which rely on per fd
>> state [3].
>>
>> So, this brings to the point do anonymous-fds actually improve
>> performance on native fuse mounts? If not, we can disable them. May be they
>> are useful for light weight metadata operations like fstat, but the
>> workload should only be limited to them. Note that anonymous fds are used
>> by open-behind by only two fops - readv and fstat. But, [1] has shown that
>> they actually regress performance for sequential reads.
>>
>
>
> Perhaps a more intelligent open-behind based on size could help? IIRC,
> open-behind was originally developed to improve latency for small file
> operations. For large files, it is unnecessary and can affect read-ahead
> behavior as observed in the referenced bugs. Could we alter the behavior to
> disable open-behind for those files which are bigger than a configurable
> size threshold?
>
+1, this sounds like a perfect solution which doesn't give out the benefits
(may be in few cases) but also doesn't reduce the performance in small file
read. We could enable open behind only for fd with rd-only, and if the size
is less than or equal to the quick-read file size.

Regards,
Poornima


> Thanks,
> Vijay
>
>
>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1419807
>> [2] https://bugzilla.redhat.com/1489513, "read-ahead underperrforms
>> expectations"
>>   open-behind without patch (MiB/s) with patch (MiB/s)
>>   on  132.87133.51
>>   off 139.70139.77
>>
>> [3] https://bugzilla.redhat.com/show_bug.cgi?id=1084508
>>
>> PS: Anonymous fds are stateless fds, where a client like native fuse
>> mount doesn't do an explicit open. Instead, bricks do the open on-demand
>> during fops which need an fd (like readv, fstat etc).
>>
>> regards,
>> Raghavendra
>>
>> ___
>> 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
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [master][FAILED] test ./tests/bugs/cli/bug-1169302.t

[Poornima Gurusiddaiah]

It has failed only on this patch [1]. Were you able to reproduce it locally
as well? Have you rebased your patch with the latest master, and tried
running?

[1]
https://fstat.gluster.org/failure/171?start_date=2018-05-04_date=2018-06-11=master

Regards,
Poornima

On Mon, Jun 11, 2018 at 8:40 AM, Milind Changire 
wrote:

> The test fails for my patch https://review.gluster.org/15811
>
> Could somebody take a look and see what the issue is
> https://build.gluster.org/job/centos7-regression/1372/consoleFull
>
> I've tried to reproduce the issue on my CentOS 7.x VM system but the test
> passes without problems.
>
> @Poornima
> Since git log on that test file shows your name at the topmost commit,
> I've decided to ping you for the same.
>
>
> --
> Milind
>
>
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Any mature(better) solution(way) to handle slow performance on 'ls -l, '.

[Poornima Gurusiddaiah]

If you are not using applications that rely on 100% metadata consistency,
like Databases, Kafka, AMQ etc. you can use the below mentioned volume
options:

# gluster volume set  group metadata-cache

# gluster volume set  network.inode-lru-limit 20

# gluster volume set  performance.readdir-ahead on

# gluster volume set  performance.parallel-readdir on

For more information refer to [1]

Also, which version og Gluster are you using? Its preferred to use 3.11 or
above for these perf enhancements.
Note that parallel-readdir is going to help in increasing the ls -l
performance drastically in your case, but there are few corner case known
issues.

Regards,
Poornima

[1]
https://github.com/gluster/glusterdocs/pull/342/files#diff-62f536ad33b2c2210d023b0cffec2c64

On Wed, May 30, 2018, 8:29 PM Yanfei Wang  wrote:

> Hi experts on glusterFS,
>
> In our testbed, we found that the ' ls -l' performance is pretty slow.
> Indeed from the prospect of glusterFS design space, we need to avoid
> 'ls ' directory which will traverse all bricks sequentially in our
> current knowledge.
>
> We use generic setting for our testbed:
>
> ```
> Volume Name: gv0
> Type: Distributed-Replicate
> Volume ID: 4a6f96f8-b3fb-4550-bd19-e1a5dffad4d0
> Status: Started
> Snapshot Count: 0
> Number of Bricks: 19 x 3 = 57
> Transport-type: tcp
> Bricks:
> ...
> Options Reconfigured:
> features.inode-quota: off
> features.quota: off
> cluster.quorum-reads: on
> cluster.quorum-count: 2
> cluster.quorum-type: fixed
> transport.address-family: inet
> nfs.disable: on
> performance.client-io-threads: off
> cluster.server-quorum-ratio: 51%
>
> ```
>


> Carefully consulting docs, the NFS client is preferred client solution
> for better 'ls' performance. However, this better performance comes
> from caching meta info locally, I think, and the caching mechanism
> will cause the penalty  of data coherence, right?
>
> I want to know what's the best or mature way to trade-off the 'ls '
> performance with data coherence in in reality? Any comments are
> welcome.
>
> Thanks.
>
> -Fei
> ___
> 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

Re: [Gluster-devel] Using syncop_readdir inside Xlator

[Poornima Gurusiddaiah]

On Tue, Mar 27, 2018, 8:48 PM David Spisla  wrote:

> Dear Gluster Devels,
>
> I want to read all the entries in a DIR inside of a xlator. For this
> purpose I use the syncop_readdir function which is also used in die
> self-heal functionality for example.
> Here is a piece of code from inside the worm_rename function:
>
>
>fd_t *fd = NULL;
>gf_dirent_t   entries;
>
> fd = fd_anonymous (oldloc->inode);
> if (fd == NULL) {
> gf_log (this->name, GF_LOG_ERROR, "fd creation
> failed");
> ret = -ENOMEM;
> goto out;
> }
> INIT_LIST_HEAD ();
> ret = syncop_readdir (this, fd, 131072, 0, , NULL,
> NULL);
> if (ret) {
>

Readdir returns the number of entries read, hence ret will be > 0, if there
are dir entries read and it's a success case. The check should be ret < 0.
If it fails with ret < 0 case then I would suspect fd_anonymous, I m not
sure whether it works for readdir, need to check the code.

Regards,
Poornima

gf_log (this->name, GF_LOG_ERROR, "failed getting
> dir entries");
> ret = -ENOMEM;
> goto out;
>}
>
> The problem is, that I always get the Error: "failed getting dir entries"
> . It seems to be that there is something wrong with the execution of that
> function. Any ideas?
>
> Regards
> David Spisla
> ___
> 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

Re: [Gluster-devel] Release 4.1: LTM release targeted for end of May

[Poornima Gurusiddaiah]

Hi,

Below are the features we are targeting for 4.1:

1. https://github.com/gluster/glusterfs/issues/364 - Write behind aggregate.
The patch is merged, documentation is pending.

2. https://github.com/gluster/glusterfs/issues/274 - Re-read dentry cache
 The patch is under review, hopefully will be merged by EOW.
Performance number evaluation and documentation is pending.

3. https://github.com/gluster/glusterfs/issues/242 - gfproxy
 Some of the patches are merged, some more under development and
review. Will update the patch list in issue.

Thanks,
Poornima


On Tue, Mar 13, 2018 at 7:07 AM, Shyam Ranganathan 
wrote:

> Hi,
>
> As we wind down on 4.0 activities (waiting on docs to hit the site, and
> packages to be available in CentOS repositories before announcing the
> release), it is time to start preparing for the 4.1 release.
>
> 4.1 is where we have GD2 fully functional and shipping with migration
> tools to aid Glusterd to GlusterD2 migrations.
>
> Other than the above, this is a call out for features that are in the
> works for 4.1. Please *post* the github issues to the *devel lists* that
> you would like as a part of 4.1, and also mention the current state of
> development.
>
> Further, as we hit end of March, we would make it mandatory for features
> to have required spec and doc labels, before the code is merged, so
> factor in efforts for the same if not already done.
>
> Current 4.1 project release lane is empty! I cleaned it up, because I
> want to hear from all as to what content to add, than add things marked
> with the 4.1 milestone by default.
>
> Thanks,
> Shyam
> P.S: Also any volunteers to shadow/participate/run 4.1 as a release owner?
> ___
> 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

[Gluster-devel] gfproxy

[Poornima Gurusiddaiah]

Hi, 

This mail is regarding the gfproxy feature, please go through the same and let 
us know your thoughts. 

About the gfproxy feature: 
--- 
As per the current architecture of Gluster, the client is more intelligent and 
has all the clustering logic. This approach has its own pros and cons. In 
several use cases, it is desirable to have all this clustering logic on the 
server side and have, as thin client as possible. Eg: Samba, Qemu, Block device 
export etc. This makes the upgrades easier, and is more scalable as the 
resources consumed by thin clients are much less than normal client. 

Approach: 
Client volfile is split into two volfiles: 
1. Thin client volfile: master(gfapi/Fuse) followed by Protocol/client 
2. gfproxyd volfile: protocol/server, performance xlators, cluster xlators, 
protocol/servers. 
With this model, the thin client connects to gfproxyd and glusterd(like 
always). gfproxyd connects to all the bricks. The major problem with this is 
performance, when the client and gfproxyd are not co-located. 


What is already done by Facebook: 
- 
1. Volgen code for generating thin client volfile and the gfproxyd daemon 
volfile. 
2. AHA translator on the thin client, so that on a restart/network disruptions 
between thin client and gfproxyd, we retry fops and the client doesn't become 
inaccessible. 


What remains to be done: 
- 
1. Glusterd managing the gfproxyd 
Currently the gfproxy daemon listens on 4 port, if we want to run multiple 
gfproxyd (one per volume) 
2. Redo the volgen and daemon management in glusterd2 
- Ability to be able to run daemons on subset of cluster nodes 
- ssl 
- Validate with other features like snap, tier, 
3. Graph switch for the gfproxyd 
4. Failover from one gfproxyd to another 
5. Less resource consumption on thin client - Memory and threads 
6. Performance analysis 

Issue: https://github.com/gluster/glusterfs/issues/242 

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

Re: [Gluster-devel] Regarding positioning of nl-cache in gluster client stack

[Poornima Gurusiddaiah]

The only requirement on positioning of nl-cache is its good to load it below 
md-cache. 
It should be ok to load it between shard and DHT. 

Regards, 
Poornima 
- Original Message -

> From: "Pranith Kumar Karampuri" <pkara...@redhat.com>
> To: "Krutika Dhananjay" <kdhan...@redhat.com>
> Cc: "Poornima Gurusiddaiah" <pguru...@redhat.com>, "Gluster Devel"
> <gluster-devel@gluster.org>
> Sent: Monday, July 17, 2017 11:34:52 AM
> Subject: Re: Regarding positioning of nl-cache in gluster client stack

> On Mon, Jul 17, 2017 at 11:31 AM, Krutika Dhananjay < kdhan...@redhat.com >
> wrote:

> > Hi Poornima and Pranith,
> 

> > I see that currently glusterd loads nl-cache between stat-prefetch and
> > open-behind on the client stack. Were there any specific considerations for
> > selecting this position for nl-cache?
> 

> > I was interested to see the performance impact of loading this translator
> > between shard and DHT in the VM store use case stack in terms of reducing
> > the number of lookups shard would have to do to figure out if a shard is
> > already created or not, since shard does its own management of .shard and
> > the files under it.
> 

> > So with this background, do you see any issues with loading nl-cache above
> > DHT in the client stack?
> 

> Nothing I can think of at the moment.

> > -Krutika
> 

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

Re: [Gluster-devel] Announcing release 3.11 : Scope, schedule and feature tracking

[Poornima Gurusiddaiah]

- Original Message -
> From: "Shyam" 
> To: "Gluster Devel" 
> Cc: gluster-us...@gluster.org
> Sent: Thursday, April 13, 2017 8:17:34 PM
> Subject: Re: [Gluster-devel] Announcing release 3.11 : Scope, schedule and 
> feature tracking
> 
> On 02/28/2017 10:17 AM, Shyam wrote:
> > Hi,
> >
> > With release 3.10 shipped [1], it is time to set the dates for release
> > 3.11 (and subsequently 4.0).
> >
> > This mail has the following sections, so please read or revisit as needed,
> >   - Release 3.11 dates (the schedule)
> >   - 3.11 focus areas
> 
> Pinging the list on the above 2 items.
> 
> > *Release 3.11 dates:*
> > Based on our release schedule [2], 3.11 would be 3 months from the 3.10
> > release and would be a Short Term Maintenance (STM) release.
> >
> > This puts 3.11 schedule as (working from the release date backwards):
> > - Release: May 30th, 2017
> > - Branching: April 27th, 2017
> 
> Branching is about 2 weeks away, other than the initial set of overflow
> features from 3.10 nothing else has been raised on the lists and in
> github as requests for 3.11.
> 
> So, a reminder to folks who are working on features, to raise the
> relevant github issue for the same, and post it to devel list for
> consideration in 3.11 (also this helps tracking and ensuring we are
> waiting for the right things at the time of branching).
> 
> >
> > *3.11 focus areas:*
> > As maintainers of gluster, we want to harden testing around the various
> > gluster features in this release. Towards this the focus area for this
> > release are,
> >
> > 1) Testing improvements in Gluster
> >   - Primary focus would be to get automated test cases to determine
> > release health, rather than repeating a manual exercise every 3 months
> >   - Further, we would also attempt to focus on maturing Glusto[7] for
> > this, and other needs (as much as possible)
> >
> > 2) Merge all (or as much as possible) Facebook patches into master, and
> > hence into release 3.11
> >   - Facebook has (as announced earlier [3]) started posting their
> > patches mainline, and this needs some attention to make it into master
> >
> 
> Further to the above, we are also considering the following features for
> this release, request feature owners to let us know if these are
> actively being worked on and if these will make the branching dates.
> (calling out folks that I think are the current feature owners for the same)
> 
> 1) Halo - Initial Cut (@pranith)
> 2) IPv6 support (@kaushal)
> 3) Negative lookup (@poornima)

Issue: https://github.com/gluster/glusterfs/issues/82
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1442569
Patch: https://review.gluster.org/#/c/16952/
This feature is targeted for 3.11 as an experimental feature and mostly for
SMB users only.

> 4) Parallel Readdirp - More changes to default settings. (@poornima, @du)
I think we should let it be optional for another release,
until it stabilizes. However, for this release we would like to make it
production feature (not experimental). I have raised the issue for
the same: https://github.com/gluster/glusterfs/issues/166

Also for 3.11, one more item would be to make the md-cache improvements
production feature, it is experimental currently. Issue for the same:
https://github.com/gluster/glusterfs/issues/167

Will add the release notes for all these features in the issues. I do not have
permissions to add labels though.

Thanks,
Poornima
> 
> > [1] 3.10 release announcement:
> > http://lists.gluster.org/pipermail/gluster-devel/2017-February/052188.html
> >
> > [2] Gluster release schedule:
> > https://www.gluster.org/community/release-schedule/
> >
> > [3] Mail regarding facebook patches:
> > http://lists.gluster.org/pipermail/gluster-devel/2016-December/051784.html
> >
> > [4] Release scope: https://github.com/gluster/glusterfs/projects/1
> >
> > [5] glusterfs github issues: https://github.com/gluster/glusterfs/issues
> >
> > [6] github issues for features and major fixes:
> > https://hackmd.io/s/BkgH8sdtg#
> >
> > [7] Glusto tests: https://github.com/gluster/glusto-tests
> > ___
> > 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
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] What does xdata mean? "gfid-req"?

[Poornima Gurusiddaiah]

- Original Message -
> From: "Soumya Koduri" <skod...@redhat.com>
> To: "Zhitao Li" <zhitaoli1...@outlook.com>, "Gluster Devel" 
> <gluster-devel@gluster.org>
> Cc: "Zhitao Li" <zhitaoli1...@163.com>, 1318078...@qq.com, "Poornima 
> Gurusiddaiah" <pguru...@redhat.com>
> Sent: Monday, March 20, 2017 2:21:12 PM
> Subject: Re: [Gluster-devel] What does xdata mean? "gfid-req"?
> 
> 
> 
> On 03/18/2017 06:51 PM, Zhitao Li wrote:
> > Hello, everyone,
> >
> >
> > I am investigating  the difference between stat and lookup operations in
> > GlusterFs now. In the translator named "md_cache", stat operation will
> > hit the cache generally, while lookup operation will miss the cache.
> >
> >
> > The reason is that for lookup operation, md_cache will check whether the
> > xdata is satisfied. In my case, lookup will include xdata "gfid-req"
> > filled by fuse-bridge. However, in md_cache, this check never pass
> > because the load flag of mdc_key "gfid-req"  is always 0.
> 
> Client(in this case fuse-bridge) generates gfid and sets it as xdata
> 'gfid-req' key during the first lookup so as to let server heal the
> file/dir with the missing gfid (if any) with the newly generated one.
> 
> I guess md-cache ignores the LOOKUP fop with this xdata key set as it
> implies that its the first lookup done by the client. Even if it doesn't
> filter it out, the file/dir entry will not be present in the
> cache then. Subsequent LOOKUPs should be served from md-cache. Poornima
> (cc'ed) shall be able to clarify the actual reason.

Yes, gfid-req will be set only on the first lookup. If not then that definitely
needs to be looked at.

> 
> Thanks,
> Soumya
> 
> >
> >
> > Could anyone tell me why "gfid-req" is filled by
> > fuse-bridge.c(fuse_getattr: nodeid==1->lookup)? What does it mean? And
> > how xdata is used?
> 
> 
> >
> > If no xdata, what would happen?
> >
> > Thank you!
> >
> >
> > Best regards,
> > Zhitao Li
> >
> > Sent from Outlook <http://aka.ms/weboutlook>
> >
> >
> > ___
> > 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

Re: [Gluster-devel] Release 3.10 testing update: Older client unable to mount post upgrade

[Poornima Gurusiddaiah]

I think this is because of the commit 96fb3562. In this 3 options, which were
already in readdir-ahead but not exposed as volume set, were exposed as
volume set options(allowed to be set with op-version GD_OP_VERSION_3_9_1):
rda-request-size, rda-low-wmark, rda-cache-limit, rda-high-wmark 
Along with this, the type of rda-request-size was changed from INT to SIZE_t.
I think the new volfiles contain 'rda-request-size 128KB' but the old client
can only understand INT.

This cannot be documented and left, it has to be fixed. One way would be to
retain the type of rda-request-size as INT, but may be there is a better way
need to check.

Regards,
Poornima

- Original Message -
> From: "Shyam" <srang...@redhat.com>
> To: "Gluster Devel" <gluster-devel@gluster.org>, "Raghavendra Gowdappa" 
> <rgowd...@redhat.com>, "Poornima
> Gurusiddaiah" <pguru...@redhat.com>, "Atin Mukherjee" <amukh...@redhat.com>
> Sent: Friday, February 17, 2017 5:36:07 AM
> Subject: Release 3.10 testing update: Older client unable to mount post 
> upgrade
> 
> Hi,
> 
> Post upgrading brick nodes from 3.8.8 to 3.10rc0 (sort of), I tried a to
> mount from a 3.8.8 client (as I had not upgraded the client till then).
> The mount failed with the following in the logs (at the end of the mail).
> 
> The issue was that I did an rpm -U to get the latest version, so all vol
> files were upgraded (from the spec file, glusterd --xlator-option
> *.upgrade=on -N), this resulted in client vol files being upgraded as
> well, and now the client does not understand the option as below,
> 
> 0-testvolssd-readdir-ahead: invalid number format "128KB" in option
> "rda-request-size"
> 0-testvolssd-readdir-ahead: validate of rda-request-size returned -1
> 0-testvolssd-readdir-ahead: validation failed: invalid number format
> "128KB" in option "rda-request-size"
> 
> So is this a bug? Or something to document? or, am I missing something?
> Poornima/Du/Atin?
> 
> Thanks,
> Shyam
> 
> ::Full logs::
> # mount -t glusterfs 10.21.76.10:/testvolssd /mnt/testvol1
> Mount failed. Please check the log file for more details.
> 
> # cat /var/log/glusterfs/mnt-testvol1.log
> [2017-02-16 17:37:12.703983] I [MSGID: 100030] [glusterfsd.c:2454:main]
> 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.8.8
> (args: /usr/sbin/glusterfs --volfile-server=10.21.76.10
> --volfile-id=/testvolssd /mnt/testvol1)
> [2017-02-16 17:37:12.726213] I [MSGID: 101190]
> [event-epoll.c:628:event_dispatch_epoll_worker] 0-epoll: Started thread
> with index 1
> [2017-02-16 17:37:12.744187] E [MSGID: 101002]
> [options.c:69:xlator_option_validate_int] 0-testvolssd-readdir-ahead:
> invalid number format "128KB" in option "rda-request-size"
> [2017-02-16 17:37:12.744221] W [MSGID: 101029]
> [options.c:945:xl_opt_validate] 0-testvolssd-readdir-ahead: validate of
> rda-request-size returned -1
> [2017-02-16 17:37:12.744235] E [MSGID: 101090]
> [graph.c:301:glusterfs_graph_validate_options]
> 0-testvolssd-readdir-ahead: validation failed: invalid number format
> "128KB" in option "rda-request-size"
> [2017-02-16 17:37:12.744248] E [MSGID: 101090]
> [graph.c:665:glusterfs_graph_activate] 0-graph: validate options failed
> [2017-02-16 17:37:12.753368] W [glusterfsd.c:1327:cleanup_and_exit]
> (-->/usr/sbin/glusterfs(mgmt_getspec_cbk+0x3c1) [0x7fbf4eb38eb1]
> -->/usr/sbin/glusterfs(glusterfs_process_volfp+0x172) [0x7fbf4eb335d2]
> -->/usr/sbin/glusterfs(cleanup_and_exit+0x6b) [0x7fbf4eb32b4b] ) 0-:
> received signum (1), shutting down
> [2017-02-16 17:37:12.753420] I [fuse-bridge.c:5794:fini] 0-fuse:
> Unmounting '/mnt/testvol1'.
> [2017-02-16 17:37:12.753957] W [glusterfsd.c:1327:cleanup_and_exit]
> (-->/lib64/libpthread.so.0(+0x7dc5) [0x7fbf4d49edc5]
> -->/usr/sbin/glusterfs(glusterfs_sigwaiter+0xe5) [0x7fbf4eb32cd5]
> -->/usr/sbin/glusterfs(cleanup_and_exit+0x6b) [0x7fbf4eb32b4b] ) 0-:
> received signum (15), shutting down
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Regarding a md-cache patch for 3.10

[Poornima Gurusiddaiah]

Hi, 

We had a patch http://review.gluster.org/#/c/16296/ which basically 
caches security.ima xattr, and hence increases the create performance by 
a considerable %. Is it possible to take this for 3.10? 
If there are no objections can the 3.10 backport of this [1] be taken ? 

[1] https://review.gluster.org/#/c/16460 

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

Re: [Gluster-devel] Release 3.10 feature proposal:: Statedump for libgfapi

[Poornima Gurusiddaiah]

- Original Message -
> From: "Niels de Vos" 
> To: "Shyam" 
> Cc: "Rajesh Joseph" , "Gluster Devel" 
> , integrat...@gluster.org,
> "Poornima G" 
> Sent: Monday, January 9, 2017 5:05:14 PM
> Subject: Re: [Gluster-devel] Release 3.10 feature proposal:: Statedump for 
> libgfapi
> 
> On Mon, Jan 09, 2017 at 10:27:03AM +0530, Shyam wrote:
> > On 01/05/2017 07:10 PM, Niels de Vos wrote:
> ...
> > > Because we would really like this in 3.10 to allow applications to
> > > integrate better with Gluster, I propose to split the functionality over
> > > several changes:
> > > 
> > > 1. ground work and API exposed for applications (and testing)
> > 
> > Poornima is working on this as a part of the patch posted at [0]. Poornima
> > do you want to add more details here?
> 
> Yes, I'm waiting for a reply rom Poornima as well. I'd like a discussion
> about an extendible interface that is not limited to doing statedumps. I
> do have patches for this based on her work and I want to share those in
> the discussion.
> 
> > > 2. enablement through a simple interface, similar to /proc/sysrq-trigger
> > > 3. enablement through gluster-cli command
> > 
> > The initial implementation of triggering a statedump via the CLI already
> > exists as a part of the patch [0].
> 
> Yes, and I am aware of that. But I also like patches to be modular and
> have split for each single functionality. That makes it easier for
> testing and reviewing. The current approach is a large chunk that I
> would like to see split. Again, waiting for Poornima to join the
> discussion.
>
> > > These options should be explained in the feature page, with the plan to
> > > provide the three options for 3.10. I'm happy to massage the patch from
> > > Poornima [0] and split it in 1 and 3. Additional improvements for 3
> > > might be needed, and we'll have to see who does that work. Point 2 is
> > > something I'll take on as well.
> > >

>From the methods mentioned 1, 3 are there as a part of the single patch. As you
mentioned the api is not extendable and glusterd requires some improvements. And
also the patch needs to be split, since you already have the patches ready, 
please
go ahead. I can abandon this patch. It would be very useful if we can get either
approach 2 or 3 for 3.10.

Thanks,
Poornima

> > > What do others think about this?
> > 
> > My question thus is, where are we drawing a line for this in 3.10
> > considering we have about a *week* left for *branching*?
> >   - Is 1, and 3 enough as it exists (i.e with the intention of exposing the
> > API as in 1 additionally)?
> 
> The API does not exist (well, it was added this morning). But the API
> needs discussion because it is not extendible. This discussion needs to
> be had, and with the new feature page we can actually do that somewhere.
> 
> >   - Is 2 mandatory or can come in later (i.e 3.11)?
> 
> It can come later, but the feature would be kess useful if this does not
> exist. Statedumps are helpful to diagnose network/communication
> problems, relying on the network to trigger them is probably not helpful
> in many situations.
> 
> >   - Is additions to 3 (i.e improvements to the gluster cli) mandatory or
> >   can
> > come in later (i.e 3.11)?
> 
> I see 1 as mandatory. The other interfaces would be welcome, but need
> discussion and approval from different component maintainers and the
> target users.
> 
> HTH,
> Niels
> 
> 
> > 
> > > 
> > > Thanks,
> > > Niels
> > > 
> > > [0] http://review.gluster.org/9228
> > [1] http://review.gluster.org/16357
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Regarding a consistent gfapi .t failure

[Poornima Gurusiddaiah]

Oh ok. I see that in ./tests/basic/gfapi/bug1291259.c the function 
glfs_upcall_get_reason() is causing segmentation fault, as per the stderr 
messages. 
Adding Niels, if he wants to take a look at this. 

We can mark the test bad by raising a Bz i suppose. 

Thanks, 
Poornima 

- Original Message -

> From: "Krutika Dhananjay" <kdhan...@redhat.com>
> To: "Poornima Gurusiddaiah" <pguru...@redhat.com>
> Cc: "Soumya Koduri" <skod...@redhat.com>, "Pranith Karampuri"
> <pkara...@redhat.com>
> Sent: Wednesday, December 14, 2016 1:49:27 AM
> Subject: Re: Regarding a consistent gfapi .t failure

> No unfortunately I had no success with recreating the failure either on my
> setup or on a borrowed centos from jenkins cluster.

> Ok this is good information. I didn't know it had failed on other patches
> too. I thought it's only with my patch.
> Can this be marked as a bad test in that case?

> -Krutika

> On Wed, Dec 14, 2016 at 12:08 PM, Poornima Gurusiddaiah < pguru...@redhat.com
> > wrote:

> > Hi,
> 

> > Are you able consistently reproduce this on your local system as well? If
> > so
> > can you share the system?
> 
> > I see that it has failed for many other patches as well.
> > http://fstat.gluster.org/weeks/1/failure/34
> 

> > Regards,
> 
> > Poornima
> 

> > > From: "Krutika Dhananjay" < kdhan...@redhat.com >
> > 
> 
> > > To: "Poornima Gurusiddaiah" < pguru...@redhat.com >, "Soumya Koduri" <
> > > skod...@redhat.com >
> > 
> 
> > > Cc: "Pranith Karampuri" < pkara...@redhat.com >
> > 
> 
> > > Sent: Tuesday, December 13, 2016 8:47:57 AM
> > 
> 
> > > Subject: Regarding a consistent gfapi .t failure
> > 
> 

> > > Hi,
> > 
> 

> > > The test tests/basic/gfapi/bug1291259.t seems to be failing consistently
> > > on
> > > my 3.9 backport http://review.gluster.org/#/c/16046/
> > 
> 

> > > The patch itself makes changes only in compound fops, so it is unlikely
> > > that
> > > the failure is caused by the patch itself.
> > 
> 

> > > Here's a sample failure run:
> > > https://build.gluster.org/job/centos6-regression/2134/console
> > 
> 

> > > I ran the test on my laptop and it passes consistently.
> > 
> 
> > > I ran the test on a borrowed centos slave and it passes there as well.
> > 
> 
> > > I looked at the logfile bug1291259.log from the archived build failure
> > > logs
> > 
> 
> > > but there are no failures.
> > 
> 

> > > If you have any ideas on how to proceed further, could you please suggest
> > > the
> > > same?
> > 
> 

> > > -Krutika
> > 
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Review request for 3.9 patches

[Poornima Gurusiddaiah]

Hi, 

Below are some of the backported patches that are important for 3.9, please 
review the same: 

http://review.gluster.org/#/c/15890/ (afr,dht,ec: Replace 
GF_EVENT_CHILD_MODIFIED with event SOME_DESCENDENT_DOWN/UP) 
http://review.gluster.org/#/c/15933/ , http://review.gluster.org/#/c/15935/ 
(libglusterfs: Fix a read hang) 
http://review.gluster.org/#/c/15959/ (afr: Fix the EIO that can occur in 
afr_inode_refresh as a result) 
http://review.gluster.org/#/c/15960/ (tests: Fix one of the md-cache test 
cases) 
http://review.gluster.org/#/c/16022/ (dht/md-cache: Filter invalidate if the 
file is made a linkto file) 

Thank You. 

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

[Gluster-devel] Release 3.10 feature proposal : Parallel readdirp

[Poornima Gurusiddaiah]

Hi, 

Currently, the readdirp at the dht layer is issued to all the bricks in a 
sequential manner. 
This greatly reduces the performance of directory enumeration in large 
clusters. 
Hence proposing to make readdirp parallel. 

Here is the BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1401812 

Design doc: http://review.gluster.org/#/c/16090/ 

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

Re: [Gluster-devel] Upstream smoke test failures

[Poornima Gurusiddaiah]

Hi, 

Have posted a fix for hang in read : http://review.gluster.org/15901 
I think, it will fix the issue reported here. Please check the commit message 
of the patch 
for more details. 

Regards, 
Poornima 
- Original Message -

> From: "Nithya Balachandran" 
> To: "Raghavendra Gowdappa" 
> Cc: "Gluster Devel" 
> Sent: Tuesday, November 22, 2016 3:23:59 AM
> Subject: Re: [Gluster-devel] Upstream smoke test failures

> On 22 November 2016 at 13:09, Raghavendra Gowdappa < rgowd...@redhat.com >
> wrote:

> > - Original Message -
> 
> > > From: "Vijay Bellur" < vbel...@redhat.com >
> 
> > > To: "Nithya Balachandran" < nbala...@redhat.com >
> 
> > > Cc: "Gluster Devel" < gluster-devel@gluster.org >
> 
> > > Sent: Wednesday, November 16, 2016 9:41:12 AM
> 
> > > Subject: Re: [Gluster-devel] Upstream smoke test failures
> 
> > >
> 
> > > On Tue, Nov 15, 2016 at 8:40 AM, Nithya Balachandran
> 
> > > < nbala...@redhat.com > wrote:
> 
> > > >
> 
> > > >
> 
> > > > On 15 November 2016 at 18:55, Vijay Bellur < vbel...@redhat.com >
> > > > wrote:
> 
> > > >>
> 
> > > >> On Mon, Nov 14, 2016 at 10:34 PM, Nithya Balachandran
> 
> > > >> < nbala...@redhat.com > wrote:
> 
> > > >> >
> 
> > > >> >
> 
> > > >> > On 14 November 2016 at 21:38, Vijay Bellur < vbel...@redhat.com >
> > > >> > wrote:
> 
> > > >> >>
> 
> > > >> >> I would prefer that we disable dbench only if we have an owner for
> 
> > > >> >> fixing the problem and re-enabling it as part of smoke tests.
> > > >> >> Running
> 
> > > >> >> dbench seamlessly on gluster has worked for a long while and if it
> > > >> >> is
> 
> > > >> >> failing today, we need to address this regression asap.
> 
> > > >> >>
> 
> > > >> >> Does anybody have more context or clues on why dbench is failing
> > > >> >> now?
> 
> > > >> >>
> 
> > > >> > While I agree that it needs to be looked at asap, leaving it in
> > > >> > until
> > > >> > we
> 
> > > >> > get
> 
> > > >> > an owner seems rather pointless as all it does is hold up various
> 
> > > >> > patches
> 
> > > >> > and waste machine time. Re-triggering it multiple times so that it
> 
> > > >> > eventually passes does not add anything to the regression test
> > > >> > processes
> 
> > > >> > or
> 
> > > >> > validate the patch as we know there is a problem.
> 
> > > >> >
> 
> > > >> > I would vote for removing it and assigning someone to look at it
> 
> > > >> > immediately.
> 
> > > >> >
> 
> > > >>
> 
> > > >> From the debugging done so far can we identify an owner to whom this
> 
> > > >> can be assigned? I looked around for related discussions and could
> 
> > > >> figure out that we are looking to get statedumps. Do we have more
> 
> > > >> information/context beyond this?
> 
> > > >>
> 
> > > > I have updated the BZ (
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1379228 )
> 
> > > > with info from the last failure - looks like hangs in write-behind and
> 
> > > > read-ahead.
> 
> > > >
> 
> > >
> 
> > >
> 
> > > I spent some time on this today and it does look like write-behind is
> 
> > > absorbing READs without performing any WIND/UNWIND actions. I have
> 
> > > attached a statedump from a slave that had the dbench problem (thanks,
> 
> > > Nigel!) to the above bug.
> 
> > >
> 
> > > Snip from statedump:
> 
> > >
> 
> > > [global.callpool.stack.2]
> 
> > > stack=0x7fd970002cdc
> 
> > > uid=0
> 
> > > gid=0
> 
> > > pid=31884
> 
> > > unique=37870
> 
> > > lk-owner=
> 
> > > op=READ
> 
> > > type=1
> 
> > > cnt=2
> 
> > >
> 
> > > [global.callpool.stack.2.frame.1]
> 
> > > frame=0x7fd9700036ac
> 
> > > ref_count=0
> 
> > > translator=patchy-read-ahead
> 
> > > complete=0
> 
> > > parent=patchy-readdir-ahead
> 
> > > wind_from=ra_page_fault
> 
> > > wind_to=FIRST_CHILD (fault_frame->this)->fops->readv
> 
> > > unwind_to=ra_fault_cbk
> 
> > >
> 
> > > [global.callpool.stack.2.frame.2]
> 
> > > frame=0x7fd97000346c
> 
> > > ref_count=1
> 
> > > translator=patchy-readdir-ahead
> 
> > > complete=0
> 
> > >
> 
> > >
> 
> > > Note that the frame which was wound from ra_page_fault() to
> 
> > > write-behind is not yet complete and write-behind has not progressed
> 
> > > the call. There are several callstacks with a similar signature in
> 
> > > statedump.
> 

> > I think the culprit here is read-ahead, not write-behind. If read fop was
> > dropped in write-behind, we should've seen a frame associated with
> > write-behind (complete=0 for a frame associated with a xlator indicates
> > frame was not unwound from _that_ xlator). But I didn't see any. Also empty
> > request queues in wb_inode corroborate the hypothesis. K
> 
> We have seen both . See comment#17 in
> https://bugzilla.redhat.com/show_bug.cgi?id=1379228 .

> regards,
> Nithya

> > arthick subrahmanya is working on a similar issue reported by a user.
> > However, we've not made much of a progress till now.
> 

> > >
> 
> > > In write-behind's readv 

[Gluster-devel] Dht crash in regression

[Poornima Gurusiddaiah]

Hi, 

I see that dht (rebalance?) has generated core during regression run on 3.7 
branch, please take a look. 
https://build.gluster.org/job/centos6-regression/1632/consoleFull 

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

Re: [Gluster-devel] Progress about small files performance

[Poornima Gurusiddaiah]

Hi, 

There has been some work that is being done on improving the small file 
performance. 
Few of the many steps were md-cache enhancements, compound fops implementation. 
Both these will be available with 3.9 release. There are many more improvements 
planned [1]. 


[1] https://www.youtube.com/watch?v=CkScAjL1GEk 

Regards, 
Poornima 

- Original Message -


From: "Gandalf Corvotempesta"  
To: "Gluster Devel"  
Sent: Wednesday, October 26, 2016 2:23:08 AM 
Subject: [Gluster-devel] Progress about small files performance 



Any progress about the major issue with gluster: the small files performance? 

Anyone working on this? 

I would really like to use gluster as storage for maildirs or web hosting, but 
with the current performance this wouldn't be possible without adding 
additional layers (like exporting huge files with iscsi or creating an NFS VM 
on top of gluster) 
___ 
Gluster-devel mailing list 
Gluster-devel@gluster.org 
http://www.gluster.org/mailman/listinfo/gluster-devel 



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

Re: [Gluster-devel] Dht readdir filtering out names

[Poornima Gurusiddaiah]

In gfapi, we pass down readdirp, irrespective of whether the application called 
readdir/readdirp. 
Hence the behaviour will be same for samba and Ganesha i suppose. 

Regards, 
Poornima 

- Original Message -

> From: "Pranith Kumar Karampuri" <pkara...@redhat.com>
> To: "Raghavendra Gowdappa" <rgowd...@redhat.com>, "Poornima Gurusiddaiah"
> <pguru...@redhat.com>, "Raghavendra Talur" <rta...@redhat.com>, "Soumya
> Koduri" <skod...@redhat.com>
> Cc: "Shyam Ranganathan" <srang...@redhat.com>, "Nithya Balachandran"
> <nbala...@redhat.com>, "Gluster Devel" <gluster-devel@gluster.org>
> Sent: Friday, September 30, 2016 12:38:06 AM
> Subject: Re: Dht readdir filtering out names

> Does samba/gfapi/nfs-ganesha have options to disable readdirp?

> On Fri, Sep 30, 2016 at 10:04 AM, Pranith Kumar Karampuri <
> pkara...@redhat.com > wrote:

> > What if the lower xlators want to set the entry->inode to NULL and clear
> > the
> > entry->d_stat to force a lookup on the name? i.e. gfid-split-brain/ia_type
> > mismatches.
> 

> > On Fri, Sep 30, 2016 at 10:00 AM, Raghavendra Gowdappa <
> > rgowd...@redhat.com
> > > wrote:
> 

> > > - Original Message -
> > 
> 
> > > > From: "Raghavendra Gowdappa" < rgowd...@redhat.com >
> > 
> 
> > > > To: "Pranith Kumar Karampuri" < pkara...@redhat.com >
> > 
> 
> > > > Cc: "Shyam Ranganathan" < srang...@redhat.com >, "Nithya Balachandran"
> > > > <
> > > > nbala...@redhat.com >, "Gluster Devel"
> > 
> 
> > > > < gluster-devel@gluster.org >
> > 
> 
> > > > Sent: Friday, September 30, 2016 9:58:34 AM
> > 
> 
> > > > Subject: Re: Dht readdir filtering out names
> > 
> 
> > > >
> > 
> 
> > > >
> > 
> 
> > > >
> > 
> 
> > > > - Original Message -
> > 
> 
> > > > > From: "Pranith Kumar Karampuri" < pkara...@redhat.com >
> > 
> 
> > > > > To: "Raghavendra Gowdappa" < rgowd...@redhat.com >
> > 
> 
> > > > > Cc: "Shyam Ranganathan" < srang...@redhat.com >, "Nithya
> > > > > Balachandran"
> > 
> 
> > > > > < nbala...@redhat.com >, "Gluster Devel"
> > 
> 
> > > > > < gluster-devel@gluster.org >
> > 
> 
> > > > > Sent: Friday, September 30, 2016 9:53:44 AM
> > 
> 
> > > > > Subject: Re: Dht readdir filtering out names
> > 
> 
> > > > >
> > 
> 
> > > > > On Fri, Sep 30, 2016 at 9:50 AM, Raghavendra Gowdappa <
> > > > > rgowd...@redhat.com >
> > 
> 
> > > > > wrote:
> > 
> 
> > > > >
> > 
> 
> > > > > >
> > 
> 
> > > > > >
> > 
> 
> > > > > > - Original Message -
> > 
> 
> > > > > > > From: "Pranith Kumar Karampuri" < pkara...@redhat.com >
> > 
> 
> > > > > > > To: "Raghavendra Gowdappa" < rgowd...@redhat.com >
> > 
> 
> > > > > > > Cc: "Shyam Ranganathan" < srang...@redhat.com >, "Nithya
> > > > > > > Balachandran" <
> > 
> 
> > > > > > nbala...@redhat.com >, "Gluster Devel"
> > 
> 
> > > > > > > < gluster-devel@gluster.org >
> > 
> 
> > > > > > > Sent: Friday, September 30, 2016 9:15:04 AM
> > 
> 
> > > > > > > Subject: Re: Dht readdir filtering out names
> > 
> 
> > > > > > >
> > 
> 
> > > > > > > On Fri, Sep 30, 2016 at 9:13 AM, Raghavendra Gowdappa <
> > 
> 
> > > > > > rgowd...@redhat.com >
> > 
> 
> > > > > > > wrote:
> > 
> 
> > > > > > >
> > 
> 
> > > > > > > > dht_readdirp_cbk has different behaviour for directories and
> > > > > > > > files.
> > 
> 
> > > > > > > >
> > 
> 
> > > > > > > > 1. If file, pick the dentry (passed from subvols as part of
> > > > >

Re: [Gluster-devel] libgfapi zero copy write - application in samba, nfs-ganesha

[Poornima Gurusiddaiah]

W.r.t Samba consuming this, it requires a great deal of code change in Samba.
Currently samba has no concept of getting buf from the underlying file system,
the filesystem comes into picture only at the last layer(gluster plugin),
where system calls are replaced by libgfapi calls. Hence, this is not readily
consumable by Samba, and i think same will be the case with NFS_Ganesha, will
let the Ganesha folksc comment on the same.


Regards,
Poornima

- Original Message -
> From: "Ric Wheeler" 
> To: "Raghavendra Gowdappa" , "Ric Wheeler" 
> 
> Cc: "Ben England" , "Gluster Devel" 
> , "Ben Turner"
> 
> Sent: Tuesday, September 27, 2016 2:25:40 AM
> Subject: Re: [Gluster-devel] libgfapi zero copy write - application in samba, 
> nfs-ganesha
> 
> On 09/27/2016 08:53 AM, Raghavendra Gowdappa wrote:
> >
> > - Original Message -
> >> From: "Ric Wheeler" 
> >> To: "Raghavendra Gowdappa" , "Saravanakumar Arumugam"
> >> 
> >> Cc: "Gluster Devel" , "Ben Turner"
> >> , "Ben England"
> >> 
> >> Sent: Tuesday, September 27, 2016 10:51:48 AM
> >> Subject: Re: [Gluster-devel] libgfapi zero copy write - application in
> >> samba, nfs-ganesha
> >>
> >> On 09/27/2016 07:56 AM, Raghavendra Gowdappa wrote:
> >>> +Manoj, +Ben turner, +Ben England.
> >>>
> >>> @Perf-team,
> >>>
> >>> Do you think the gains are significant enough, so that smb and
> >>> nfs-ganesha
> >>> team can start thinking about consuming this change?
> >>>
> >>> regards,
> >>> Raghavendra
> >> This is a large gain but I think that we might see even larger gains (a
> >> lot
> >> depends on how we implement copy offload :)).
> > Can you elaborate on what you mean "copy offload"? If it is the way we
> > avoid a copy in gfapi (from application buffer), following is the
> > workflow:
> >
> > 
> >
> > Work flow of zero copy write operation:
> > --
> >
> > 1) Application requests a buffer of specific size. A new buffer is
> > allocated from iobuf pool, and this buffer is passed on to application.
> > Achieved using "glfs_get_buffer"
> >
> > 2) Application writes into the received buffer, and passes that to
> > libgfapi, and libgfapi in turn passes the same buffer to underlying
> > translators. This avoids a memcpy in glfs write
> > Achieved using "glfs_zero_write"
> >
> > 3) Once the write operation is complete, Application must take the
> > responsibilty of freeing the buffer.
> > Achieved using "glfs_free_buffer"
> >
> > 
> >
> > Do you've any suggestions/improvements on this? I think Shyam mentioned an
> > alternative approach (for zero-copy readv I think), let me look up at that
> > too.
> >
> > regards,
> > Raghavendra
> 
> Both NFS and SMB support a copy offload that allows a client to produce a new
> copy of a file without bringing data over the wire. Both, if I remember
> correctly, do a ranged copy within a file.
> 

Yup, also referred to as Server side copy, Niels is working on having this for 
Gluster.

> The key here is that since the data does not move over the wire from server
> to
> client, we can shift the performance bottleneck to the storage server.
> 
> If we have a slow (1GB) link between client and server, we should be able to
> do
> that copy as if it happened just on the server itself. For a single NFS
> server
> (not a clustered, scale out server), that usually means we are as fast as the
> local file system copy.
> 
> Note that there are also servers that simply "reflink" that file, so we have
> a
> very small amount of time needed on the server to produce that copy.  This
> can
> be a huge win for say a copy of a virtual machine guest image.
> 
> Gluster and other distributed servers won't benefit as much as a local server
> would I suspect because of the need to do things internally over our networks
> between storage server nodes.
> 
> Hope that makes my thoughts clearer?
> 
> Here is a link to a brief overview of the new Linux system call:
> 
> https://kernelnewbies.org/Linux_4.5#head-6df3d298d8e0afa8e85e1125cc54d5f13b9a0d8c
> 
> Note that block devices or pseudo devices can also implement a copy offload.
> 
> Regards,
> 
> Ric
> 
> >
> >> Worth looking at how we can make use of it.
> >>
> >> thanks!
> >>
> >> Ric
> >>
> >>> - Original Message -
>  From: "Saravanakumar Arumugam" 
>  To: "Gluster Devel" 
>  Sent: Monday, September 26, 2016 7:18:26 PM
>  Subject: [Gluster-devel] libgfapi zero copy write - application in
>  samba,
>   nfs-ganesha
> 
>  Hi,
> 
>  I have carried out "basic" performance measurement with zero copy write
>  APIs.
>  Throughput of zero copy write is 57 MB/sec vs default write 43 MB/sec.
> 

Re: [Gluster-devel] review request - Change the way client uuid is built

[Poornima Gurusiddaiah]

- Original Message -
> From: "Niels de Vos" 
> To: "Raghavendra Gowdappa" 
> Cc: "Gluster Devel" 
> Sent: Wednesday, September 21, 2016 3:52:39 AM
> Subject: Re: [Gluster-devel] review request - Change the way client uuid is 
> built
> 
> On Wed, Sep 21, 2016 at 01:47:34AM -0400, Raghavendra Gowdappa wrote:
> > Hi all,
> > 
> > [1] might have implications across different components in the stack. Your
> > reviews are requested.
> > 
> > 
> > 
> > rpc : Change the way client uuid is built
> > 
> > Problem:
> > Today the main users of client uuid are protocol layers, locks, leases.
> > Protocolo layers requires each client uuid to be unique, even across
> > connects and disconnects. Locks and leases on the server side also use
> > the same client uid which changes across graph switches and across
> > file migrations. Which makes the graph switch and file migration
> > tedious for locks and leases.
> > As of today lock migration across graph switch is client driven,
> > i.e. when a graph switches, the client reassociates all the locks(which
> > were associated with the old graph client uid) with the new graphs
> > client uid. This means flood of fops to get and set locks for each fd.
> > Also file migration across bricks becomes even more difficult as
> > client uuid for the same client, is different on the other brick.
> > 
> > The exact set of issues exists for leases as well.
> > 
> > Hence the solution:
> > Make the migration of locks and leases during graph switch and migration,
> > server driven instead of client driven. This can be achieved by changing
> > the format of client uuid.
> > 
> > Client uuid currently:
> > %s(ctx uuid)-%s(protocol client name)-%d(graph id)%s(setvolume
> > count/reconnect count)
> > 
> > Proposed Client uuid:
> > "CTX_ID:%s-GRAPH_ID:%d-PID:%d-HOST:%s-PC_NAME:%s-RECON_NO:%s"
> > -  CTX_ID: This is will be constant per client.
> > -  GRAPH_ID, PID, HOST, PC_NAME(protocol client name), RECON_NO(setvolume
> > count)
> > remains the same.
> > 
> > With this, the first part of the client uuid, CTX_ID+GRAPH_ID remains
> > constant across file migration, thus the migration is made easier.
> > 
> > Locks and leases store only the first part CTX_ID+GRAPH_ID as their
> > client identification. This means, when the new graph connects,
> > the locks and leases xlator should walk through their database
> > to update the client id, to have new GRAPH_ID. Thus the graph switch
> > is made server driven and saves a lot of network traffic.
> 
> What is the plan to have the CTX_ID+GRAPH_ID shared over multiple gfapi
> applications? This would be important for NFS-Ganesha failover where one
> NFS-Ganesha process is stopped, and the NFS-Clients (by virtual-ip) move
> to an other NFS-Ganesha server.
> 
Sharing it across multiple gfapi applications is currently not supported.
Do you mean, setting the CTX_ID+GRAPH_ID at the init of the other client,
or during replay of locks during the failover?
If its the former, we need an api in gfapi to take the CTX_ID+GRAPH_ID as
an argument and other things.
> Will there be a way to set CTX_ID(+GRAPH_ID?) through libgfapi? That
> would allow us to add a configuration option to NFS-Ganesha and have the
> whole NFS-Ganesha cluster use the same locking/leases.
Ah, ok. the whole of cluster will have the same CTX_ID(+GRAPH_ID?), but then
the cleanup logic will not work, as the disconnect cleanup happens as soon as
one of the NFS-Ganesha disconnects?

This patch doesn't eliminate the migration that is required during graph switch,
it still is necessary, but it can be server driven instead of client driven.
> 
> Thanks,
> Niels
> 
> 
> > 
> > Change-Id: Ia81d57a9693207cd325d7b26aee4593fcbd6482c
> > BUG: 1369028
> > Signed-off-by: Poornima G 
> > Signed-off-by: Susant Palai 
> > 
> > 
> > 
> > [1] http://review.gluster.org/#/c/13901/10/
> > 
> > regards,
> > Raghavendra
> > ___
> > Gluster-devel mailing list
> > Gluster-devel@gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
> 
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Review request for 3.9 patches

[Poornima Gurusiddaiah]

Hi All,

There are 3 more patches that we need for enabling md-cache invalidation in 3.9.
Request your help with the reviews:

http://review.gluster.org/#/c/15378/   - afr: Implement IPC fop
http://review.gluster.org/#/c/15387/   - ec: Implement IPC fop
http://review.gluster.org/#/c/15398/   - mdc/upcall/afr: Reduce the window of 
stale read


Thanks,
Poornima

- Original Message -
> From: "Poornima Gurusiddaiah" <pguru...@redhat.com>
> To: "Gluster Devel" <gluster-devel@gluster.org>, "Raghavendra Gowdappa" 
> <rgowd...@redhat.com>, "Rajesh Joseph"
> <rjos...@redhat.com>, "Raghavendra Talur" <rta...@redhat.com>, "Soumya 
> Koduri" <skod...@redhat.com>, "Niels de Vos"
> <nde...@redhat.com>, "Anoop Chirayath Manjiyil Sajan" <achir...@redhat.com>
> Sent: Tuesday, August 30, 2016 5:13:36 AM
> Subject: Re: [Gluster-devel] Review request for 3.9 patches
> 
> Hi,
> 
> Few more patches, have addressed the review comments, could you please review
> these patches:
> 
> http://review.gluster.org/15002   md-cache: Register the list of xattrs with
> cache-invalidation
> http://review.gluster.org/15300   dht, md-cache, upcall: Add invalidation of
> IATT when the layout changes
> http://review.gluster.org/15324   md-cache: Process all the cache
> invalidation flags
> http://review.gluster.org/15313   upcall: Mark the clients as accessed even
> on readdir entries
> http://review.gluster.org/15193   io-stats: Add stats for upcall
> notifications
> 
> Regards,
> Poornima
> 
> - Original Message -
> 
> > From: "Poornima Gurusiddaiah" <pguru...@redhat.com>
> > To: "Gluster Devel" <gluster-devel@gluster.org>, "Raghavendra Gowdappa"
> > <rgowd...@redhat.com>, "Rajesh Joseph" <rjos...@redhat.com>, "Raghavendra
> > Talur" <rta...@redhat.com>, "Soumya Koduri" <skod...@redhat.com>, "Niels de
> > Vos" <nde...@redhat.com>, "Anoop Chirayath Manjiyil Sajan"
> > <achir...@redhat.com>
> > Sent: Thursday, August 25, 2016 5:22:43 AM
> > Subject: Review request for 3.9 patches
> 
> > Hi,
> 
> > There are few patches that are part of the effort of integrating md-cache
> > with upcall.
> > Hope to take these patches for 3.9, it would be great if you can review
> > these
> > patches:
> 
> > upcall patches:
> > http://review.gluster.org/#/c/15313/
> > http://review.gluster.org/#/c/15301/
> 
> > md-cache patches:
> > http://review.gluster.org/#/c/15002/
> > http://review.gluster.org/#/c/15045/
> > http://review.gluster.org/#/c/15185/
> > http://review.gluster.org/#/c/15224/
> > http://review.gluster.org/#/c/15225/
> > http://review.gluster.org/#/c/15300/
> > http://review.gluster.org/#/c/15314/
> 
> > Thanks,
> > Poornima
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Fix master and 3.9 regression

[Poornima Gurusiddaiah]

Hi, 

Currently the master and 3.9 regression is broken. This is because we do not 
have regression 
run just before merge(rebase). Patches http://review.gluster.org/#/c/15385/ and 
http://review.gluster.org/#/c/15386 fixes the same, Is it possible to merge 
these patches 
at the earliest, as they are stuck in spurious regression failures? 

Thanks, 
Poornima 

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

Re: [Gluster-devel] Review request for 3.9 patches

[Poornima Gurusiddaiah]

Hi,

Few more patches, have addressed the review comments, could you please review 
these patches:

http://review.gluster.org/15002   md-cache: Register the list of xattrs with 
cache-invalidation
http://review.gluster.org/15300   dht, md-cache, upcall: Add invalidation of 
IATT when the layout changes
http://review.gluster.org/15324   md-cache: Process all the cache invalidation 
flags
http://review.gluster.org/15313   upcall: Mark the clients as accessed even on 
readdir entries
http://review.gluster.org/15193   io-stats: Add stats for upcall notifications

Regards,
Poornima

- Original Message - 

> From: "Poornima Gurusiddaiah" <pguru...@redhat.com>
> To: "Gluster Devel" <gluster-devel@gluster.org>, "Raghavendra Gowdappa"
> <rgowd...@redhat.com>, "Rajesh Joseph" <rjos...@redhat.com>, "Raghavendra
> Talur" <rta...@redhat.com>, "Soumya Koduri" <skod...@redhat.com>, "Niels de
> Vos" <nde...@redhat.com>, "Anoop Chirayath Manjiyil Sajan"
> <achir...@redhat.com>
> Sent: Thursday, August 25, 2016 5:22:43 AM
> Subject: Review request for 3.9 patches

> Hi,

> There are few patches that are part of the effort of integrating md-cache
> with upcall.
> Hope to take these patches for 3.9, it would be great if you can review these
> patches:

> upcall patches:
> http://review.gluster.org/#/c/15313/
> http://review.gluster.org/#/c/15301/

> md-cache patches:
> http://review.gluster.org/#/c/15002/
> http://review.gluster.org/#/c/15045/
> http://review.gluster.org/#/c/15185/
> http://review.gluster.org/#/c/15224/
> http://review.gluster.org/#/c/15225/
> http://review.gluster.org/#/c/15300/
> http://review.gluster.org/#/c/15314/

> Thanks,
> Poornima
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] mainline compilation fails

[Poornima Gurusiddaiah]

Hi, 

Regarding the enforcement of the dependencies while merging, i see that 
the dependent patches on any patch is mentioned in the "Related Changes" 
column [1]. It still doesn't enforce, in the cherry-pick way of
submitting changes, by default it ignores the lineage [2]. But there are
ways to enforce this. Will let the gluster infra maintainers to comment
on the same.

[1] 
https://gerrit-review.googlesource.com/Documentation/user-review-ui.html#related-changes
[2] 
https://gerrit-review.googlesource.com/Documentation/project-configuration.html#project_options

Regards,
Poornima
- Original Message - 

> From: "Prasanna Kalever" 
> To: "Atin Mukherjee" 
> Cc: "Gluster Devel" 
> Sent: Saturday, August 27, 2016 11:11:33 AM
> Subject: Re: [Gluster-devel] mainline compilation fails

> Oops!
> Didn't noticed these changes were part of parent/child patches, Just
> noticed "BUILD BROKEN" and went into action :)

> I'm not sure about it!

> If it takes time to decide on whether the other set of patches need to
> be taken or not, at-least my patch will fix the broken build (That
> much I can assure)

> Lets see if the regressions break after these patch goes in (mostly
> not, that I see from the code)

> Thanks,
> --
> Prasanna

> On Sat, Aug 27, 2016 at 8:34 PM, Atin Mukherjee
>  wrote:
> >
> >
> > On Saturday 27 August 2016, Prasanna Kalever  wrote:
> >>
> >> Here is the patch that should fix it
> >> http://review.gluster.org/#/c/15331/
> >
> >
> > Thanks! Well thats an easy way, but the question here is dont we need the
> > parent patch to be merged to ensure there is no other functionality broken.
> > Currently I see that the parent patch has a -1, in that case is it required
> > to revert 15225?
> >>
> >>
> >> Happy weekend!
> >>
> >> --
> >> Prasanna
> >>
> >>
> >> On Sat, Aug 27, 2016 at 7:49 PM, Atin Mukherjee 
> >> wrote:
> >> > [1] has broken mainline compilation and I feel this could be because its
> >> > parent patch is not been merged otherwise smoke should have caught it.
> >> > Please resolve it at earliest.
> >> >
> >> > [1] http://review.gluster.org/#/c/15225/
> >> >
> >> >
> >> > --Atin
> >> >
> >> > ___
> >> > Gluster-devel mailing list
> >> > Gluster-devel@gluster.org
> >> > http://www.gluster.org/mailman/listinfo/gluster-devel
> >> ___
> >> Gluster-devel mailing list
> >> Gluster-devel@gluster.org
> >> http://www.gluster.org/mailman/listinfo/gluster-devel
> >
> >
> >
> > --
> > --Atin
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] 3.9. feature freeze status check

[Poornima Gurusiddaiah]

Hi, 

Updated inline. 

- Original Message -

> From: "Pranith Kumar Karampuri" <pkara...@redhat.com>
> To: "Rajesh Joseph" <rjos...@redhat.com>, "Manikandan Selvaganesh"
> <mselv...@redhat.com>, "Csaba Henk" <ch...@redhat.com>, "Niels de Vos"
> <nde...@redhat.com>, "Jiffin Thottan" <jthot...@redhat.com>, "Aravinda
> Vishwanathapura Krishna Murthy" <avish...@redhat.com>, "Anoop Chirayath
> Manjiyil Sajan" <achir...@redhat.com>, "Ravishankar Narayanankutty"
> <ravishan...@redhat.com>, "Kaushal Madappa" <kmada...@redhat.com>,
> "Raghavendra Talur" <rta...@redhat.com>, "Poornima Gurusiddaiah"
> <pguru...@redhat.com>, "Soumya Koduri" <skod...@redhat.com>, "Kaleb
> Keithley" <kkeit...@redhat.com>, "Jose Rivera" <jriv...@redhat.com>,
> "Prashanth Pai" <p...@redhat.com>, "Samikshan Bairagya"
> <sbair...@redhat.com>, "Vijay Bellur" <vbel...@redhat.com>, "Prasanna
> Kalever" <pkale...@redhat.com>
> Cc: "Gluster Devel" <gluster-devel@gluster.org>
> Sent: Friday, August 26, 2016 12:21:07 PM
> Subject: Re: 3.9. feature freeze status check

> Prasanna, Prashant,
> Could you add a short description of the features you are working on for 3.9
> as well to the list?

> On Fri, Aug 26, 2016 at 9:39 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com > wrote:

> > On Fri, Aug 26, 2016 at 9:38 PM, Pranith Kumar Karampuri <
> > pkara...@redhat.com > wrote:
> 

> > > hi,
> > 
> 
> > > Now that we are almost near the feature freeze date (31st of Aug), want
> > > to
> > > get a sense if any of the status of the features.
> > 
> 

> > I meant "want to get a sense of the status of the features"
> 

> > > Please respond with:
> > 
> 
> > > 1) Feature already merged
> > 
> 
> > > 2) Undergoing review will make it by 31st Aug
> > 
> 
> > > 3) Undergoing review, but may not make it by 31st Aug
> > 
> 
> > > 4) Feature won't make it for 3.9.
> > 
> 

> > > I added the features that were not planned(i.e. not in the 3.9 roadmap
> > > page)
> > > but made it to the release and not planned but may make it to release at
> > > the
> > > end of this mail.
> > 
> 
> > > If you added a feature on master that will be released as part of 3.9.0
> > > but
> > > forgot to add it to roadmap page, please let me know I will add it.
> > 
> 

> > > Here are the features planned as per the roadmap:
> > 
> 
> > > 1) Throttling
> > 
> 
> > > Feature owner: Ravishankar
> > 
> 

> > > 2) Trash improvements
> > 
> 
> > > Feature owners: Anoop, Jiffin
> > 
> 

> > > 3) Kerberos for Gluster protocols:
> > 
> 
> > > Feature owners: Niels, Csaba
> > 
> 

> > > 4) SELinux on gluster volumes:
> > 
> 
> > > Feature owners: Niels, Manikandan
> > 
> 

> > > 5) Native sub-directory mounts:
> > 
> 
> > > Feature owners: Kaushal, Pranith
> > 
> 

> > > 6) RichACL support for GlusterFS:
> > 
> 
> > > Feature owners: Rajesh Joseph
> > 
> 

> > > 7) Sharemodes/Share reservations:
> > 
> 
> > > Feature owners: Raghavendra Talur, Poornima G, Soumya Koduri, Rajesh
> > > Joseph,
> > > Anoop C S
> > 
> 

> > > 8) Integrate with external resource management software
> > 
> 
> > > Feature owners: Kaleb Keithley, Jose Rivera
> > 
> 

> > > 9) Python Wrappers for Gluster CLI Commands
> > 
> 
> > > Feature owners: Aravinda VK
> > 
> 

> > > 10) Package and ship libgfapi-python
> > 
> 
> > > Feature owners: Prashant Pai
> > 
> 

> > > 11) Management REST APIs
> > 
> 
> > > Feature owners: Aravinda VK
> > 
> 

> > > 12) Events APIs
> > 
> 
> > > Feature owners: Aravinda VK
> > 
> 

> > > 13) CLI to get state representation of a cluster from the local glusterd
> > > pov
> > 
> 
> > > Feature owners: Samikshan Bairagya
> > 
> 

> > > 14) Posix-locks Reclaim support
> > 
> 
> > > Feature owners: Soumya Koduri
> > 
> 

> > > 15) Deprecate striped volumes
> > 
> 
> > 

[Gluster-devel] Review request for 3.9 patches

[Poornima Gurusiddaiah]

Hi, 

There are few patches that are part of the effort of integrating md-cache with 
upcall. 
Hope to take these patches for 3.9, it would be great if you can review these 
patches: 

upcall patches: 
http://review.gluster.org/#/c/15313/ 
http://review.gluster.org/#/c/15301/ 

md-cache patches: 
http://review.gluster.org/#/c/15002/ 
http://review.gluster.org/#/c/15045/ 
http://review.gluster.org/#/c/15185/ 
http://review.gluster.org/#/c/15224/ 
http://review.gluster.org/#/c/15225/ 
http://review.gluster.org/#/c/15300/ 
http://review.gluster.org/#/c/15314/ 

Thanks, 
Poornima 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] [Gluster-users] CFP Gluster Developer Summit

[Poornima Gurusiddaiah]

Hi,

Myself and Rajesh Joseph would like to present on:

Topic: Performance bottlenecks for metadata workload in Gluster
Category: Performance and Stability
Abstract:
Will be presenting the analysis on the profile info for different
metadata workload- create, listing, rename, copy etc. and what are the
existing bottlenecks, and how to make it better. Also on some of the tunables
for small file performance. In any case will be putting up a documentation
on this on glusterdocs.

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

[Gluster-devel] md-cache changes and impact on tiering

[Poornima Gurusiddaiah]

Hi, 

The basic patches for md-cache and integrating it with cache-invalidation is 
merged in master. You could try master build and enable the following settings, 
to see if there is any impact on tiering performance at all: 

# gluster volume set  performance.stat-prefetch on 
# gluster volume set  features.cache-invalidation on 
# gluster volume set  performance.cache-samba-metadata on 
# gluster volume set  performance.md-cache-timeout 600 
# gluster volume set  features.cache-invalidation-timeout 600 

Note: It has to be executed in the same order. 

Tracker bug: https://bugzilla.redhat.com/show_bug.cgi?id=1211863 
Patches: 
http://review.gluster.org/#/q/status:open+project:glusterfs+branch:master+topic:bug-1211863
 

Thanks, 
Poornima 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Glusterfs 3.7.11 with LibGFApi in Qemu on Ubuntu Xenial does not work

[Poornima Gurusiddaiah]

Hi, 

Because of the bugs: 
https://bugzilla.redhat.com/show_bug.cgi?id=1350880 
https://bugzilla.redhat.com/show_bug.cgi?id=1352482 

3.7.11 is not a good version to be on for Qemu use case, please update to 
3.7.13, which has fix for both the bugs. 

W.R.T your original permission denied issue, please check the firewall 
settings, and also check if its not selinux issue. 

Regards, 
Poornima 
- Original Message -

> From: "Stephen Howell" 
> To: gluster-devel@gluster.org
> Sent: Saturday, August 20, 2016 7:54:48 AM
> Subject: [Gluster-devel] Glusterfs 3.7.11 with LibGFApi in Qemu on Ubuntu
> Xenial does not work

> I would like to follow up on a previous thread. I have here 3 machines
> running Ubuntu. All were running 14.04 LTS and of these two have been
> upgraded to 16.04. They all run QEMU with a shared GlusterFS mount for
> storing VM images. Libgfapi was configured and running on all hosts with
> 14.04 but has stopped recently with 16.04.

> I can see exactly the same problems as mentioned here on the 16.04 machines,
> with these packages:

> ii glusterfs-client 3.7.14-ubuntu1~xenial1 amd64 clustered file-system
> (client package)
> ii glusterfs-common 3.7.14-ubuntu1~xenial1 amd64 GlusterFS common libraries
> and translator modules
> ii glusterfs-server 3.7.14-ubuntu1~xenial1 amd64 clustered file-system
> (server package)
> ii qemu-block-extra:amd64 1:2.5+dfsg-5ubuntu10.2glusterfs3.7.14xenial1 amd64
> extra block backend modules for qemu-system and qemu-utils
> ii qemu-kvm 1:2.5+dfsg-5ubuntu10.2glusterfs3.7.14xenial1 amd64 QEMU Full
> virtualization
> ii qemu-system-common 1:2.5+dfsg-5ubuntu10.2glusterfs3.7.14xenial1 amd64 QEMU
> full system emulation binaries (common files)
> ii qemu-system-x86 1:2.5+dfsg-5ubuntu10.2glusterfs3.7.14xenial1 amd64 QEMU
> full system emulation binaries (x86)
> ii qemu-utils 1:2.5+dfsg-5ubuntu10.2glusterfs3.7.14xenial1 amd64 QEMU
> utilities

> Packages on the 14.04 instance:

> ii glusterfs-client 3.7.13-ubuntu1~trusty1 amd64 clustered file-system
> (client package)
> ii glusterfs-common 3.7.13-ubuntu1~trusty1 amd64 GlusterFS common libraries
> and translator modules
> ii glusterfs-server 3.7.13-ubuntu1~trusty1 amd64 clustered file-system
> (server package)
> ii qemu-common 2.0.0+dfsg-2ubuntu1.24glusterfs3.7.12trusty1 all dummy
> transitional package from qemu-common to qemu-keymaps
> ii qemu-keymaps 2.0.0+dfsg-2ubuntu1.24glusterfs3.7.12trusty1 all QEMU
> keyboard maps
> ii qemu-kvm 2.0.0+dfsg-2ubuntu1.24glusterfs3.7.12trusty1 amd64 QEMU Full
> virtualization
> ii qemu-system-common 2.0.0+dfsg-2ubuntu1.24glusterfs3.7.12trusty1 amd64 QEMU
> full system emulation binaries (common files)
> ii qemu-system-x86 2.0.0+dfsg-2ubuntu1.24glusterfs3.7.12trusty1 amd64 QEMU
> full system emulation binaries (x86)
> ii qemu-utils 2.0.0+dfsg-2ubuntu1.24glusterfs3.7.12trusty1 amd64 QEMU
> utilities

> As you can see I am using Andre (monotek)'s packages to employ the Gluster
> protocol in QEMU under Ubuntu (not compiled by default). The versions of
> Gluster are similar and have indeed been identical in my prior testing. The
> relevant volume options were set, apparmour rules were added and the setup
> worked without issue serving block devices over libgfapi for 10+ VMs.
> However on upgrading to 16.04 there are issues relating to QEMU being unable
> to access the Gluster volume file when starting a VM. I can use qemu-img to
> create a blank file using the Gluster profocol but I cannot then start a VM
> using that file.

> Error message:

> [MSGID: 104007] [glfs-mgmt.c:637:glfs_mgmt_getspec_cbk] 0-glfs-mgmt: failed
> to fetch volume file (key:VM) [Invalid argument] [2016-08-20
> 11:28:02.985483] E [MSGID: 104024] [glfs-mgmt.c:738:mgmt_rpc_notify]
> 0-glfs-mgmt: failed to connect with remote-host: 127.0.0.1 (Permission
> denied) [Permission denied] 2016-08-20T11:28:03.979968Z qemu-system-x86_64:
> -drive file=gluster://
> 127.0.0.1/VM/vm1.qcow2,format=qcow2,if=none,id=drive-virtio-disk0,cache=none
> : Gluster connection failed for server=127.0.0.1 port=0 volume=VM
> image=vm1.qcow2 transport=tcp: Permission denied

> Any assistance on changes to permissions or apparmour in 16.04 would be
> greatly appreciated.

> thanks
> Stephen

> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] md-cache improvements

[Poornima Gurusiddaiah]

My comments inline.

Regards,
Poornima

- Original Message -
> From: "Dan Lambright" 
> To: "Gluster Devel" 
> Sent: Wednesday, August 10, 2016 10:35:58 PM
> Subject: [Gluster-devel] md-cache improvements
> 
> 
> There have been recurring discussions within the gluster community to build
> on existing support for md-cache and upcalls to help performance for small
> file workloads. In certain cases, "lookup amplification" dominates data
> transfers, i.e. the cumulative round trip times of multiple LOOKUPs from the
> client mitigates benefits from faster backend storage.
> 
> To tackle this problem, one suggestion is to more aggressively utilize
> md-cache to cache inodes on the client than is currently done. The inodes
> would be cached until they are invalidated by the server.
> 
> Several gluster development engineers within the DHT, NFS, and Samba teams
> have been involved with related efforts, which have been underway for some
> time now. At this juncture, comments are requested from gluster developers.
> 
> (1) .. help call out where additional upcalls would be needed to invalidate
> stale client cache entries (in particular, need feedback from DHT/AFR
> areas),
> 
> (2) .. identify failure cases, when we cannot trust the contents of md-cache,
> e.g. when an upcall may have been dropped by the network

Yes, this needs to be handled.
It can happen only when there is a one way disconnect, where the server cannot
reach client and notify fails. We can have a retry for the same until the cache
expiry time.

> 
> (3) .. point out additional improvements which md-cache needs. For example,
> it cannot be allowed to grow unbounded.

This is being worked on, and will be targetted for 3.9

> 
> Dan
> 
> - Original Message -
> > From: "Raghavendra Gowdappa" 
> > 
> > List of areas where we need invalidation notification:
> > 1. Any changes to xattrs used by xlators to store metadata (like dht layout
> > xattr, afr xattrs etc).

Currently, md-cache will negotiate(using ipc) with the brick, a list of xattrs
that it needs invalidation for. Other xlators can add the xattrs they are 
interested
in to the ipc. But then these xlators need to manage their own caching and 
processing
the invalidation request, as md-cache will be above all cluater xlators.
reference: http://review.gluster.org/#/c/15002/

> > 2. Scenarios where individual xlator feels like it needs a lookup. For
> > example failed directory creation on non-hashed subvol in dht during mkdir.
> > Though dht succeeds mkdir, it would be better to not cache this inode as a
> > subsequent lookup will heal the directory and make things better.

For this, these xlators can specify an indicator in the dict of
the fop cbk, to not cache. This should be fairly simple to implement.

> > 3. removing of files

When an unlink is issued from the mount point, the cache is invalidated.

> > 4. writev on brick (to invalidate read cache on client)

writev on brick from any other client will invalidate the metadata cache on all
the other clients.

> > 
> > Other questions:
> > 5. Does md-cache has cache management? like lru or an upper limit for
> > cache.

Currently md-cache doesn't have any cache-management, we will be targeting this
for 3.9

> > 6. Network disconnects and invalidating cache. When a network disconnect
> > happens we need to invalidate cache for inodes present on that brick as we
> > might be missing some notifications. Current approach of purging cache of
> > all inodes might not be optimal as it might rollback benefits of caching.
> > Also, please note that network disconnects are not rare events.

Network disconnects are handled to a minimal extent, where any brick down will
cause the whole of the cache to be invalidated. Invalidating only the list of
inodes that belong to that perticular brick will need the support from the
underlying cluster xlators.

> > 
> > regards,
> > Raghavendra
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Regression failures in last 6 days

[Poornima Gurusiddaiah]

Hi, 





Below are the regression failures in the last 6 days. Could you please look 
into these. Ignore if already fixed. 





48 of 116 regressions failed 




./tests/bugs/bug-1110262.t ; Failed 6 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22623/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22598/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22593/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22576/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22569/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22551/consoleFull
 





./tests/bugs/glusterd/bug-1089668.t ; Failed 4 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22615/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22587/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22575/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22545/consoleFull
 





./tests/basic/afr/add-brick-self-heal.t ; Failed 4 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22614/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22602/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22591/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22583/consoleFull
 





./tests/basic/volume-snapshot-clone.t ; Failed 3 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22589/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22555/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22515/consoleFull
 





./tests/bugs/core/bug-834465.t ; Failed 3 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22607/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22605/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22531/consoleFull
 





./tests/bugs/posix/bug-1113960.t ; Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22528/consoleFull
 





./tests/performance/open-behind.t ; Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22572/consoleFull
 





./tests/bugs/glusterd/bug-1260185-donot-allow-detach-commit-unnecessarily.t ; 
Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22603/consoleFull
 



./tests/basic/mount-nfs-auth.t ; Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22618/consoleFull
 





./tests/features/ssl-ciphers.t ; Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22567/consoleFull
 





./tests/bugs/snapshot/bug-1316437.t ; Failed 2 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22522/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22510/consoleFull
 





./tests/basic/ec/ec.t ; Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22544/consoleFull
 





./tests/bugs/glusterd/bug-963541.t ; Failed 2 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22575/consoleFull
 


Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22549/consoleFull
 





./tests/basic/volume-snapshot.t ; Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22596/consoleFull
 





./tests/bugs/geo-replication/bug-877293.t ; Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22541/consoleFull
 





./tests/basic/afr/entry-self-heal.t ; Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22526/consoleFull
 





./tests/basic/afr/arbiter.t ; Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22523/consoleFull
 





./tests/basic/gfapi/bug-1241104.t ; Failed 1 times 

Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22539/consoleFull
 





./tests/basic/afr/durability-off.t ; Failed 2 times 

Regression Link: 

[Gluster-devel] Review request for md-cache enhancements

[Poornima Gurusiddaiah]

Hi, 

Here is a patch http://review.gluster.org/#/c/15002 that lets md-cache inform 
upcall about the list of xattrs, that it is interested, in receiving 
invalidations. Could you please take a look at this. There are dependent 
patches on this, which i will work on based on the review comments. 

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

[Gluster-devel] gfapi regression failures

[Poornima Gurusiddaiah]

Hi, 

Below is the list of gfapi test cases that failed spuriously in the last 4 days:

./tests/basic/gfapi/libgfapi-fini-hang.t ; Failed 4 times
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22477/consoleFull
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22474/consoleFull
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22471/consoleFull
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22439/consoleFull
Fix with RCA  can be found at http://review.gluster.org/#/c/14997/

./tests/bugs/gfapi/bug-1093594.t ; Failed 3 times
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22497/consoleFull
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22458/consoleFull
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22441/consoleFull
Possible fix is http://review.gluster.org/#/c/14722

./tests/basic/gfapi/bug1291259.t ; Failed 1 times
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22496/consoleFull
Soumya is looking into this one.


Can you please review the fix for the regressions, or we need to disable these 
test cases.

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

Re: [Gluster-devel] spurious failure in tests/basic/gfapi/libgfapi-fini-hang.t

[Poornima Gurusiddaiah]

Hi, 

Thanks Pranith. Here is the patch for the same: http://review.gluster.org/14997
The failure is not because there was a hang(the logs show that 
glfs_set_volfile_server was still executing), but because the EXPECT_WITHIN was 
not really waiting. And hence there was a race between the execution of the 
process gfapi_hang and the kill.

Regards,
Poornima


- Original Message - 

> From: "Pranith Kumar Karampuri" <pkara...@redhat.com>
> To: "Soumya Koduri" <skod...@redhat.com>, "Poornima Gurusiddaiah"
> <pguru...@redhat.com>
> Cc: "Gluster Devel" <gluster-devel@gluster.org>
> Sent: Saturday, July 23, 2016 8:20:36 AM
> Subject: spurious failure in tests/basic/gfapi/libgfapi-fini-hang.t

> I see both of your names in git blame output.
> https://build.gluster.org/job/rackspace-regression-2GB-triggered/22439/console
> has more information about the failure. This failure happened on
> http://review.gluster.org/#/c/14985/ which changes only .t files so I
> believe the reason for the failure to be something else. Could you please
> take a look to find if there is a problem with the test or if it caught a
> race in some recent code change?

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

[Gluster-devel] Regression failures in last 3 days

[Poornima Gurusiddaiah]

Hi, 

Below are the list of test cases that have failed regression in the last 3 
days. Please take a look at them: 

./tests/bitrot/br-stub.t ; Failed 8 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22356/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22355/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22340/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22325/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22322/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22316/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22313/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22293/consoleFull
 

./tests/bugs/snapshot/bug-1316437.t ; Failed 6 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22361/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22343/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22340/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22329/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22327/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22324/consoleFull
 

./tests/basic/afr/arbiter-mount.t ; Failed 4 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22354/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22353/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22311/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22306/consoleFull
 

./tests/basic/ec/ec.t ; Failed 3 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22335/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22290/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22287/consoleFull
 

./tests/bugs/disperse/bug-1236065.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22339/consoleFull
 

./tests/basic/afr/add-brick-self-heal.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22315/consoleFull
 

./tests/basic/tier/tierd_check.t ; Failed 2 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22299/consoleFull
 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22296/consoleFull
 

./tests/bugs/glusterd/bug-041.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22331/consoleFull
 

./tests/bugs/glusterd/bug-1089668.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22304/consoleFull
 

./tests/basic/ec/ec-new-entry.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22359/consoleFull
 

./tests/basic/uss.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22352/consoleFull
 

./tests/basic/geo-replication/marker-xattrs.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22337/consoleFull
 

./tests/basic/bd.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22351/consoleFull
 

./tests/bugs/bug-1110262.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22286/consoleFull
 

./tests/performance/open-behind.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22284/consoleFull
 

./tests/basic/quota-anon-fd-nfs.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22340/consoleFull
 

./tests/bugs/bug-1187474.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22351/consoleFull
 

./tests/basic/afr/entry-self-heal.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/22357/consoleFull
 

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

Re: [Gluster-devel] Reducing merge conflicts

[Poornima Gurusiddaiah]

Completely agree with your concern here. Keeping aside the regression part, few 
observations and suggestions:
As per the Maintainers guidelines 
(https://gluster.readthedocs.io/en/latest/Contributors-Guide/Guidelines-For-Maintainers/):

a> Merge patches of owned components only.
b> Seek approvals from all maintainers before merging a patchset spanning 
multiple components.
c> Ensure that regression tests pass for all patches before merging.
d> Ensure that regression tests accompany all patch submissions.
e> Ensure that documentation is updated for a noticeable change in user 
perceivable behavior or design.
f> Encourage code unit tests from patch submitters to improve the overall 
quality of the codebase.
g> Not merge patches written by themselves until there is a +2 Code Review 
vote by other reviewers.

Clearly a, b, are not being strictly followed, because of multiple reasons.
- Not every component in Gluster has a Maintainer
- Its getting difficult to get review time from maintainers as they are 
maintainers for several component, and they are also active developers.
- What is enforced by mere documentation of procedure, is hard to implement.

Below are the few things that we can do to reduce our review backlog:
- No time for maintainers to review is not a good enough reason to bitrot 
patches in review for months, it clearly means we need additional maintainers 
for that component?
- Add maintainers for every component that is in Gluster(atleast the ones which 
have incoming patches)
- For every patch we submit we add 'component(s)' label, and evaluate if gerrit 
can automatically add maintainers as reviewers, and have another label 
'Maintainers ack' which needs to be present for any patch to be merged.
- Before every major(or minor also?) release, any patch that is not making to 
the release should have a '-1' by the maintainer or the developer themselves 
stating the reason(preferably not no time to review).
  The release manager should ensure that there are no patches in below gerrit 
search link provided by Jeff.

Any thoughts?

Regards,
Poornima

- Original Message -
> From: "Jeff Darcy" 
> To: "Gluster Devel" 
> Sent: Friday, July 8, 2016 2:02:27 AM
> Subject: [Gluster-devel] Reducing merge conflicts
> 
> I'm sure a lot of you are pretty frustrated with how long it can take to get
> even a trivial patch through our Gerrit/Jenkins pipeline.  I know I am.
> Slow tests, spurious failures, and bikeshedding over style issues are all
> contributing factors.  I'm not here to talk about those today.  What I am
> here to talk about is the difficulty of getting somebody - anybody - to look
> at a patch and (possibly) give it the votes it needs to be merged.  To put
> it bluntly, laziness here is *killing* us.  The more patches we have in
> flight, the more merge conflicts and rebases we have to endure for each one.
> It's a quadratic effect.  That's why I personally have been trying really
> hard to get patches that have passed all regression tests and haven't gotten
> any other review attention "across the finish line" so they can be merged
> and removed from conflict with every other patch still in flight.  The
> search I use for this, every day, is as follows:
> 
> 
> http://review.gluster.org/#/q/status:open+project:glusterfs+branch:master+label:CentOS-regression%253E0+label:NetBSD-regression%253E0+-label:Code-Review%253C0
> 
> That is:
> 
> open patches on glusterfs master (change project/branch as appropriate to
> your role)
>  
> CentOS and NetBSD regression tests complete
> 
> no -1 or -2 votes which might represent legitimate cause for delay
> 
> If other people - especially team leads and release managers - could make a
> similar habit of checking the queue and helping to get such "low hanging
> fruit" out of the way, we might see an appreciable increase in our overall
> pace of development.  If not, we might have to start talking about mandatory
> reviews with deadlines and penalties for non-compliance.  I'm sure nobody
> wants to see their own patches blocked and their own deadlines missed
> because they weren't doing their part to review peers' work, but that's a
> distinct possibility.  Let's all try to get this train unstuck and back on
> track before extreme measures become necessary.
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] 3.7.12/3.8.qemu/proxmox testing

[Poornima Gurusiddaiah]

- Original Message -
> From: "Lindsay Mathieson" 
> To: "Kaushal M" , gluster-us...@gluster.org
> Cc: "Gluster Devel" 
> Sent: Monday, July 4, 2016 4:23:37 PM
> Subject: Re: [Gluster-users] 3.7.12/3.8.qemu/proxmox testing
> 
> On 4/07/2016 7:16 PM, Kaushal M wrote:
> > An update on this, we are tracking this issue on bugzilla [1].
> > I've added some of the observations made till now in the bug. Copying
> > the same here.
> 
> Thanks Kaushal, appreciate the updates.
> 

Found the RCA for the issue, an explanation of the same can be found @ 
https://bugzilla.redhat.com/show_bug.cgi?id=1352482#c8 
The patch for this, will follow shortly and hope to include it in 3.1.13

Regards,
Poornima

> 
> --
> Lindsay Mathieson
> 
> ___
> Gluster-users mailing list
> gluster-us...@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] performance issues Manoj found in EC testing

[Poornima Gurusiddaiah]

Regards, 
Poornima 

- Original Message -

> From: "Pranith Kumar Karampuri" 
> To: "Xavier Hernandez" 
> Cc: "Gluster Devel" 
> Sent: Monday, June 27, 2016 5:48:24 PM
> Subject: Re: [Gluster-devel] performance issues Manoj found in EC testing

> On Mon, Jun 27, 2016 at 12:42 PM, Pranith Kumar Karampuri <
> pkara...@redhat.com > wrote:

> > On Mon, Jun 27, 2016 at 11:52 AM, Xavier Hernandez < xhernan...@datalab.es
> > >
> > wrote:
> 

> > > Hi Manoj,
> > 
> 

> > > I always enable client-io-threads option for disperse volumes. It
> > > improves
> > > performance sensibly, most probably because of the problem you have
> > > detected.
> > 
> 

> > > I don't see any other way to solve that problem.
> > 
> 

> > I agree. Updated the bug with same info.
> 

> > > I think it would be a lot better to have a true thread pool (and maybe an
> > > I/O
> > > thread pool shared by fuse, client and server xlators) in libglusterfs
> > > instead of the io-threads xlator. This would allow each xlator to decide
> > > when and what should be parallelized in a more intelligent way, since
> > > basing
> > > the decision solely on the fop type seems too simplistic to me.
> > 
> 

> > > In the specific case of EC, there are a lot of operations to perform for
> > > a
> > > single high level fop, and not all of them require the same priority.
> > > Also
> > > some of them could be executed in parallel instead of sequentially.
> > 
> 

> > I think it is high time we actually schedule(for which release) to get this
> > in gluster. May be you should send out a doc where we can work out details?
> > I will be happy to explore options to integrate io-threads, syncop/barrier
> > with this infra based on the design may be.
> 

> I was just thinking why we can't reuse synctask framework. It already scales
> up/down based on the tasks. At max it uses 16 threads. Whatever we want to
> be executed in parallel we can create a synctask around it and run it. Would
> that be good enough?

Yes, synctask framework can be preferred over io-threads, else it would mean 16 
synctask threads + 16(?) io-threads for one instance of mount, this will blow 
out the gfapi clients if they have many mounts from the same process. Also 
using synctask would mean code changes in EC? 

> > > Xavi
> > 
> 

> > > On 25/06/16 19:42, Manoj Pillai wrote:
> > 
> 

> > > > - Original Message -
> > > 
> > 
> 

> > > > > From: "Pranith Kumar Karampuri" < pkara...@redhat.com >
> > > > 
> > > 
> > 
> 
> > > > > To: "Xavier Hernandez" < xhernan...@datalab.es >
> > > > 
> > > 
> > 
> 
> > > > > Cc: "Manoj Pillai" < mpil...@redhat.com >, "Gluster Devel" <
> > > > > gluster-devel@gluster.org >
> > > > 
> > > 
> > 
> 
> > > > > Sent: Thursday, June 23, 2016 8:50:44 PM
> > > > 
> > > 
> > 
> 
> > > > > Subject: performance issues Manoj found in EC testing
> > > > 
> > > 
> > 
> 

> > > > > hi Xavi,
> > > > 
> > > 
> > 
> 
> > > > > Meet Manoj from performance team Redhat. He has been testing EC
> > > > 
> > > 
> > 
> 
> > > > > performance in his stretch clusters. He found some interesting things
> > > > > we
> > > > 
> > > 
> > 
> 
> > > > > would like to share with you.
> > > > 
> > > 
> > 
> 

> > > > > 1) When we perform multiple streams of big file writes(12 parallel
> > > > > dds
> > > > > I
> > > > 
> > > 
> > 
> 
> > > > > think) he found one thread to be always hot (99%CPU always). He was
> > > > > asking
> > > > 
> > > 
> > 
> 
> > > > > me if fuse_reader thread does any extra processing in EC compared to
> > > > 
> > > 
> > 
> 
> > > > > replicate. Initially I thought it would just lock and epoll threads
> > > > > will
> > > > 
> > > 
> > 
> 
> > > > > perform the encoding but later realized that once we have the lock
> > > > > and
> > > > 
> > > 
> > 
> 
> > > > > version details, next writes on the file would be encoded in the same
> > > > 
> > > 
> > 
> 
> > > > > thread that comes to EC. write-behind could play a role and make the
> > > > > writes
> > > > 
> > > 
> > 
> 
> > > > > come to EC in an epoll thread but we saw consistently there was just
> > > > > one
> > > > 
> > > 
> > 
> 
> > > > > thread that is hot. Not multiple threads. We will be able to confirm
> > > > > this
> > > > 
> > > 
> > 
> 
> > > > > in tomorrow's testing.
> > > > 
> > > 
> > 
> 

> > > > > 2) This is one more thing Raghavendra G found, that our current
> > > > 
> > > 
> > 
> 
> > > > > implementation of epoll doesn't let other epoll threads pick messages
> > > > > from
> > > > 
> > > 
> > 
> 
> > > > > a socket while one thread is processing one message from that socket.
> > > > > In
> > > > 
> > > 
> > 
> 
> > > > > EC's case that can be encoding of the write/decoding read. This will
> > > > > not
> > > > 
> > > 
> > 
> 
> > > > > let replies of operations on different files to be processed in
> > > > > parallel.
> > > > 
> > > 
> > 
> 
> > > > > He thinks this can be fixed for 3.9.
> > > > 
> > > 
> 

[Gluster-devel] ./tests/basic/afr/self-heald.t regression failure

[Poornima Gurusiddaiah]

Hi, 

The test ./tests/basic/afr/self-heald.t creates a core and fails test 38, 53, 
68. 
Link for the regression 
https://build.gluster.org/job/rackspace-netbsd7-regression-triggered/17536/console
 

Can you please take a look at it? 

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

[Gluster-devel] IMPORTANT: Patches that need attention for 3.8

[Poornima Gurusiddaiah]

Hi, 

Here is the list of patches that need to go for 3.8. I request the maintainers 
of each component mentioned here to review/merge the same at the earliest: 

Protocol/RPC: 
http://review.gluster.org/#/c/14647/ 
http://review.gluster.org/#/c/14648/ 

Glusterd: 
http://review.gluster.org/#/c/14626/ 

Lease: 
http://review.gluster.org/#/c/14568/ 

Gfapi: 
http://review.gluster.org/#/q/status:open+project:glusterfs+branch:master+topic:bug-1319992
 

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

[Gluster-devel] ./tests/bugs/write-behind/bug-1279730.t is failing on unrelated patches

[Poornima Gurusiddaiah]

Hi, 

The test case has failed several times on unrelated patches 
./tests/bugs/write-behind/bug-1279730.t, one of the regression link can be 
found at 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/20942/console 
Appreciate if you can take a look at. 

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

[Gluster-devel] Usage of xdata to send anything on wire

[Poornima Gurusiddaiah]

Hi, 

In the recent past, have seen multiple instances where we needed to send some 
data along with the fop on wire. And we have been using the xdata for the same. 
Eg: 
1. Add lease-id, transaction id to every fop. 
2. Send the xattrs to invalidate in xdata. 
3. Send the share flags during open. 

There were concerns raised around this for the below reasons: 
1. word-size and endianness 
2. security issues 
3. Backward compatibility issues i.e. old/new client and server combination. 

Initiating this mail to arrive at a conclusion, whether we can use xdata or we 
need to find a different solution, if so what is the solution. 
Your thoughts comments are appreciated. 

Solution 1: 
To get rid of sending xdata on wire, one of the solution could be to have 
protocol versioning in Gluster. With this we can modify xdr structures for each 
release and get rid of xdata. But this will be huge work. 

Solution 2: 
- Change dict, to not be an opaque structure , but an array of data elements 
which is a union of (int, string etc.). 
- Backward compatibility issues is when the newer server/client adds data to 
dict but the old client/server fails to read the dict. This is the 
responsibility of the programmer to make sure, thta this case doesn't fail 
silently, op version can be used if it is done as a part of adding new 
feature/volume set. Another approach would be, if client has a list of 
capabilities(features) the server supports it can accordingly tune itself to 
access the xdata. 

Regards, 
Poornima 

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

Re: [Gluster-devel] Idea: Alternate Release process

[Poornima Gurusiddaiah]

+1 for "Proposed alternative 3 - One LTS every year and non LTS stable release 
once in every 4 months" as it is more appropriate. 

Regards, 
Poornima 

- Original Message -

> From: "Aravinda" 
> To: "Kaushal M" , "Gluster Devel"
> 
> Sent: Friday, May 13, 2016 1:46:23 PM
> Subject: Re: [Gluster-devel] Idea: Alternate Release process

> Hi,

> Based on the discussion in last community meeting and previous discussions,

> 1. Too frequent releases are difficult to manage.(without dedicated release
> manager)
> 2. Users wants to see features early for testing or POC.
> 3. Backporting patches to more than two release branches is pain

> Enclosed visualizations to understand existing release and support cycle and
> proposed alternatives.

> - Each grid interval is 6 months
> - Green rectangle shows supported release or LTS
> - Black dots are minor releases till it is supported(once a month)
> - Orange rectangle is non LTS release with minor releases(Support ends when
> next version released)

> Enclosed following images
> 1. Existing Release cycle and support plan(6 months release cycle, 3 releases
> supported all the time)
> 2. Proposed alternative 1 - One LTS every year and non LTS stable release
> once in every 2 months
> 3. Proposed alternative 2 - One LTS every year and non LTS stable release
> once in every 3 months
> 4. Proposed alternative 3 - One LTS every year and non LTS stable release
> once in every 4 months
> 5. Proposed alternative 4 - One LTS every year and non LTS stable release
> once in every 6 months (Similar to existing but only alternate one will
> become LTS)

> Please do vote for the proposed alternatives about release intervals and LTS
> releases. You can also vote for the existing plan.

> Do let me know if I missed anything.
> regards
> Aravinda
> On 05/11/2016 12:01 AM, Aravinda wrote:

> > I couldn't find any solution for the backward incompatible changes. As you
> > mentioned this model will not work for LTS.
> 

> > How about adopting this only for non LTS releases? We will not have
> > backward
> > incompatibility problem since we need not release minor updates to non LTS
> > releases.
> 
> > regards
> 
> > Aravinda
> 
> > On 05/05/2016 04:46 PM, Aravinda wrote:
> 

> > > regards
> > 
> 
> > > Aravinda
> > 
> 

> > > On 05/05/2016 03:54 PM, Kaushal M wrote:
> > 
> 

> > > > On Thu, May 5, 2016 at 11:48 AM, Aravinda  wrote:
> > > 
> > 
> 

> > > > > Hi,
> > > > 
> > > 
> > 
> 

> > > > > Sharing an idea to manage multiple releases without maintaining
> > > > 
> > > 
> > 
> 
> > > > > multiple release branches and backports.
> > > > 
> > > 
> > 
> 

> > > > > This idea is heavily inspired by the Rust release model(you may feel
> > > > 
> > > 
> > 
> 
> > > > > exactly same except the LTS part). I think Chrome/Firefox also
> > > > > follows
> > > > 
> > > 
> > 
> 
> > > > > the same model.
> > > > 
> > > 
> > 
> 

> > > > > http://blog.rust-lang.org/2014/10/30/Stability.html
> > > > 
> > > 
> > 
> 

> > > > > Feature Flag:
> > > > 
> > > 
> > 
> 
> > > > > --
> > > > 
> > > 
> > 
> 
> > > > > Compile time variable to prevent compiling featurerelated code when
> > > > 
> > > 
> > 
> 
> > > > > disabled. (For example, ./configure--disable-geo-replication
> > > > 
> > > 
> > 
> 
> > > > > or ./configure --disable-xml etc)
> > > > 
> > > 
> > 
> 

> > > > > Plan
> > > > 
> > > 
> > 
> 
> > > > > -
> > > > 
> > > 
> > 
> 
> > > > > - Nightly build with all the features enabled(./build --nightly)
> > > > 
> > > 
> > 
> 

> > > > > - All new patches will land in Master, if the patch belongs to a
> > > > 
> > > 
> > 
> 
> > > > > existing feature then it should be written behind that feature flag.
> > > > 
> > > 
> > 
> 

> > > > > - If a feature is still work in progress then it will be only enabled
> > > > > in
> > > > 
> > > 
> > 
> 
> > > > > nightly build and not enabled in beta or stable builds.
> > > > 
> > > 
> > 
> 
> > > > > Once the maintainer thinks the feature is ready for testing then that
> > > > 
> > > 
> > 
> 
> > > > > feature will be enabled in beta build.
> > > > 
> > > 
> > 
> 

> > > > > - Every 6 weeks, beta branch will be created by enabling all the
> > > > 
> > > 
> > 
> 
> > > > > features which maintainers thinks it is stable and previous beta
> > > > 
> > > 
> > 
> 
> > > > > branch will be promoted as stable.
> > > > 
> > > 
> > 
> 
> > > > > All the previous beta features will be enabled in stable unless it
> > > > 
> > > 
> > 
> 
> > > > > is marked as unstable during beta testing.
> > > > 
> > > 
> > 
> 

> > > > > - LTS builds are same as stable builds but without enabling all the
> > > > 
> > > 
> > 
> 
> > > > > features. If we decide last stable build will become LTS release,
> > > > 
> > > 
> > 
> 
> > > > > then the feature list from last stable build will be saved as
> > > > 
> > > 
> > 
> 
> > > > > `features-release-.yaml`, For 

Re: [Gluster-devel] xlator option setting in gfapi

[Poornima Gurusiddaiah]

Hi,

Reply inline

Regards,
Poornima

- Original Message -
> From: "Raghavendra Gowdappa" <rgowd...@redhat.com>
> To: "Raghavendra Talur" <rta...@redhat.com>
> Cc: "Poornima Gurusiddaiah" <pguru...@redhat.com>, "Gluster Devel" 
> <gluster-devel@gluster.org>, "Jeff Cody"
> <jc...@redhat.com>, "Rajesh Joseph" <rjos...@redhat.com>
> Sent: Monday, May 9, 2016 12:17:25 PM
> Subject: Re: xlator option setting in gfapi
> 
> 
> 
> - Original Message -
> > From: "Raghavendra Talur" <rta...@redhat.com>
> > To: "Raghavendra Gowdappa" <rgowd...@redhat.com>
> > Cc: "Poornima Gurusiddaiah" <pguru...@redhat.com>, "Gluster Devel"
> > <gluster-devel@gluster.org>, "Jeff Cody"
> > <jc...@redhat.com>, "Rajesh Joseph" <rjos...@redhat.com>
> > Sent: Monday, May 9, 2016 11:57:44 AM
> > Subject: Re: xlator option setting in gfapi
> > 
> > On Mon, May 9, 2016 at 8:45 AM, Raghavendra Gowdappa <rgowd...@redhat.com>
> > wrote:
> > 
> > > Hi Poornima/Raghavendra,
> > >
> > > This mail is an initiation of a thread to discuss how to make xlator
> > > options setting in gfapi synchronous (so, that caller will know the
> > > result)
> > > or providing a cbk to let the application know about the status.
> > >
> > > My very naive attempt of code-reading showed me that
> > > pub_glfs_set_xlator_option just adds the option to
> > > cmd_args.xlator_options.
> > > Can you please explain how/when these values are communicated to glusterd
> > > to change volfile? From there we can carry forward the conversation.
> > >
> > >
> > Raghavendra,
> > 
> > glfs_set_xlator_option is equivalent to --xlator-option of mount.glusterfs
> > of FUSE. This feature is not intended to apply the setting to the volume
> > permanently, rather it is specific to the mount and only valid for its
> > lifetime.
> > The current architecture of Gluster graph takes these options only in
> > cmd_args and then these values are given preference over whatever comes in
> > volfile from Glusterd. In essence, these settings can be used to override
> > the volume settings for a particular mount.
> 
> For this use case, even a way to modify the options for a single mount is
> fine. But the problem is, how do I know whether the option I set has taken
> effect? Is checking return value of pug_glfs_set_xlator_option is sufficient
> (seems unlikely as I don't see any xlators being involved here)? Can you
> explain the mechanism involved here (as in how this option is propagated to
> relevant xlator - do we call reconfigure with new set of option dict etc)?
> 


This is what happens when glfs_set_xlator_option is called:
- It updates ctx->cmd_args->xlator_options
- gf_add_cmdline_options (during glusterfs_graph_prepare.. pub_glfs_init) 
  adds it to xl->options
- glusterfs_graph_unknown_options (during glusterfs_graph_activate.. 
pub_glfs_init) 
  checks if the options in xl->options are present or not. If the option is not 
present
  it just logs a warning message. These options are treated as command line 
args.

To report the option setting as a failure, at the least we can fail glfs_init().
Would that be an acceptable solution? This change will also affect bricks, fuse 
mount
and other gluster processes.

> > 
> > If the requirement is to set a volume wide option then glusterd or one of
> > the REST interfaces for Glusterd should be used.
> > 
> > I will also reply to the other thread with possible methods on overcoming
> > the problem with write-behind and qemu.
> > 
> > Thanks,
> > Raghavendra Talur
> > 
> > 
> > > regards,
> > > Raghavendra
> > >
> > 
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] xlator option setting in gfapi

[Poornima Gurusiddaiah]

Hi,

This is what happens when glfs_set_xlator_option is called:
- It updates ctx->cmd_args->xlator_options
- gf_add_cmdline_options (during glusterfs_graph_prepare.. pub_glfs_init) adds 
it to xl->options
- glusterfs_graph_unknown_options (during glusterfs_graph_activate.. 
pub_glfs_init) checks if the options in xl->options are present or not. If the 
option is not present it just logs a warning message. These options are treated 
as command line args.

To report the option as a failure, at the least we can fail glfs_init()

Regards,
Poornima

- Original Message -
> From: "Raghavendra Gowdappa" <rgowd...@redhat.com>
> To: "Poornima Gurusiddaiah" <pguru...@redhat.com>, "Raghavendra Talur" 
> <rta...@redhat.com>
> Cc: "Gluster Devel" <gluster-devel@gluster.org>, "Jeff Cody" 
> <jc...@redhat.com>, "Rajesh Joseph" <rjos...@redhat.com>
> Sent: Monday, May 9, 2016 8:45:56 AM
> Subject: xlator option setting in gfapi
> 
> Hi Poornima/Raghavendra,
> 
> This mail is an initiation of a thread to discuss how to make xlator options
> setting in gfapi synchronous (so, that caller will know the result) or
> providing a cbk to let the application know about the status.
> 
> My very naive attempt of code-reading showed me that
> pub_glfs_set_xlator_option just adds the option to cmd_args.xlator_options.
> Can you please explain how/when these values are communicated to glusterd to
> change volfile? From there we can carry forward the conversation.
> 
> regards,
> Raghavendra
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Regression Summary of last week failures

[Poornima Gurusiddaiah]

Hi All, 

Using the tool extras/failed-tests.py one can get the summary of the failed 
regression in the last week. 
Have generated the same, request each of the component owners to go through and 
fix the spurious tests 
For automating this, Raghavendra Talur will add this as a job to run weekly and 
send the report to gluster-devel 

Here is the summary: 

./tests/bugs/snapshot/bug-1168875.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19513/console 
Found cores: 
Component: [u'glusterfs-20536.core'] 
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19522/console 
Component: [u'glusterfsd-24329.core'] 
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19532/console 
Component: [u'glusterfsd-25652.core'] 
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19537/console 
Component: [u'glusterd-27702.core'] 
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19538/console 
Component: [u'glusterfsd-4606.core'] 
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19543/console 
Component: [u'glusterd-27702.core'] 
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19546/console 
Component: [u'glusterfsd-13444.core'] 
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19551/console 
Component: [u'glusterfsd-2110.core'] 
Regression Link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19553/console 
./tests/basic/tier/tier.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19567/console 
./tests/bugs/quick-read/bug-846240.t ; Failed 2 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19521/console 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19571/console 
./tests/basic/afr/self-heal.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19493/console 
./tests/basic/quota-untar.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19509/console 
./tests/bugs/disperse/bug-1161621.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19511/console 
./tests/bugs/quota/bug-1293601.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19568/console 
./tests/bugs/protocol/bug-808400-repl.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19522/console 
./tests/bugs/replicate/bug-1297695.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19497/console 
./tests/basic/uss.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19502/console 
./tests/basic/ec/ec-background-heals.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19506/console 
./tests/basic/afr/gfid-self-heal.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19549/console 
./tests/basic/nsr/nsr.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19541/console 
./tests/bugs/tier/bug-1279376-rename-demoted-file.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19519/console 
./tests/basic/quota-anon-fd-nfs.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19515/console 
./tests/bugs/snapshot/bug-1109889.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19481/console 
./tests/bugs/glusterd/bug-1209329_daemon-svcs-on-reset-volume.t ; Failed 1 
times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19542/console 
./tests/basic/volume-snapshot-clone.t ; Failed 1 times 
Regression Links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/19484/console 

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

Re: [Gluster-devel] [Gluster-users] glusterfs ctdb issues

[Poornima Gurusiddaiah]

Daniel,

If filetransfer being interrupted is the only problem, then that is expected.
This is because the IP failover happens to a different node but the open file
descriptor is not transferred, to the node the IP is failed over to. Hence, the
IP failover feature provides a way of not having to umount and mount with a
different IP when the original node fails.

Once the filetranfer is interrupted and you re-initiate the transfer,
does it work fine? If so then its expected behavior.

Regards,
Poornima

- Original Message -
> From: "Daniel Filipazzi" <daniel.filipa...@med.lu.se>
> To: pguru...@redhat.com
> Sent: Thursday, March 31, 2016 6:22:00 PM
> Subject: Re: [Gluster-users] glusterfs ctdb issues
> 
> Hi again!
> I tried changing the lock file location but no sucsess.
> I also edited the files as in the guide.
> But no change just as before as soon as you shutdown one of the nodes,
> the filetransfer stops.
> 
> I have looked at several guides but no luck so far.
> 
> I would realy apriciate some help!
> 
> please let me know if theres anything you need.
> 
> Best Regards
> 
> --
> Daniel Filipazzi
> Division of Oncology
> Department of Clinical Sciences, Lund
> Lund University Cancer Center/Medicon Village
> Building 404:B3 Scheelevägen 2
> SE-223 81 Lund
> Sweden
> 
> Email: daniel.filipa...@med.lu.se
> 
> 
> 
> 
> 
> fre 2016-03-11 klockan 04:00 -0500 skrev Poornima Gurusiddaiah:
> > Hi,
> > 
> > So, you can find the documentation for configuring CTDB for gluster
> > backend here:
> > https://github.com/gluster/glusterdocs/blob/master/Administrator%20Gu
> > ide/Accessing%20Gluster%20from%20Windows.md
> > 
> > I guess you have missed creating CTDB volume and mounting it on all
> > nodes and using that volume to store ctdb lock file.
> > 
> > If that is the case, then that explains the 2 issues you are facing.
> > 
> > Also, once you follow the steps in the documentation, change the
> > ctdb.conf to:
> > CTDB_RECOVERY_LOCK=/gluster/lock
> > 
> > Will update the documentation to include this step as well.
> > 
> > Let us know if it helped.
> > 
> > Regards,
> > Poornima
> > 
> > From: "Daniel Filipazzi" <daniel.filipa...@med.lu.se>
> > To: gluster-us...@gluster.org
> > Sent: Thursday, March 10, 2016 7:17:09 PM
> > Subject: [Gluster-users] glusterfs ctdb issues
> > 
> > Ive installed glusterfs successfully and set up the ctdb module to
> > work with it.
> > When creating a new glusterfs volume glusterfs writes to smb.conf to
> > create a share automatically, the share does not work "Unable to
> > mount location".
> > I successfully created a share pointing to the gluster mount point
> > see below, but i cant get the HA feature to work.
> > 
> > 
> > This works!
> > [csmb]
> > comment = Clustered Samba
> > public = yes
> > path = /share/
> > writeable = yes
> > ea support = yes
> > 
> > And this does not.
> > 
> > [gluster-share]
> > comment = share
> > vfs objects = glusterfs
> > glusterfs:volume = share
> > glusterfs:logfile = /var/log/samba/glusterfs-share.%M.log
> > glusterfs:loglevel = 7
> > path = /
> > read only = no
> > guest ok = yes
> > 
> > I used 3 nodes with a replicated glusterfs share to test this.
> > So i have 2 issues i need solved.
> > 1. the config that glusterfs writes to smb.conf doesnt work why?
> > 2. when one of the nodes shutsdown while a client writes to a ctdb
> > share it stops completely and the client cant write to the share
> > anymore. How do i get around this?
> > The other nodes should take over so the client can be able to write
> > to the share when a node goes down.
> > 
> > The ctdb config:
> >  nodes:
> > 192.168.1.10
> > 192.168.1.11
> > 192.168.1.13
> > 
> > public_addresses:
> > 192.168.1.212/24 eth1
> > 
> > ctdb:
> > CTDB_RECOVERY_LOCK=/opt/samba-config/lockfile
> > CTDB_PUBLIC_ADDRESSES=/opt/samba-config/public_addresses
> > CTDB_MANAGES_SAMBA=yes
> > CTDB_MANAGES_WINBIND=yes
> > CTDB_LOGFILE=/var/log/log.ctdb
> > CTDB_SYSLOG=no
> > 
> > 
> > Overall im having a hard time to make ctdb work properly, i would
> > appreciate other peoples insight and thoughts around ctdb. To me it
> > doesnt realy feel like a stable product.
> > Would you advice me to use ctdb in an environment that's in
> > production?
> > 
> > Best regards
> >  
> > --
> > 
> > Daniel Filipazzi
> > Division of Oncology
> > Department of Clinical Sciences, Lund
> > Lund University Cancer Center/Medicon Village
> > Building 404:B3 Scheelevägen 2
> > SE-223 81 Lund
> > Sweden
> > 
> > Email: daniel.filipa...@med.lu.se
> > 
> > ___
> > Gluster-users mailing list
> > gluster-us...@gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-users
> > 
> 
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Regression: Core generated by fdl-overflow.t

[Poornima Gurusiddaiah]

Hi, 

In few of the regression runs, found that ./tests/features/fdl-overflow.t is 
causing a core dump. 

Here is the bt: 
/build/install/lib/libglusterfs.so.0(_gf_msg_backtrace_nomem+0xf2)[0x7f4905e5e3f6]
 
/build/install/lib/libglusterfs.so.0(gf_print_trace+0x22b)[0x7f4905e64381] 
/build/install/sbin/glusterfsd(glusterfsd_print_trace+0x1f)[0x4099f2] 
/lib64/libc.so.6(+0x326a0)[0x7f49049f06a0] 
/build/install/lib/glusterfs/3.8dev/xlator/experimental/fdl.so(fdl_worker+0x69)[0x7f48f3395529]
 
/lib64/libpthread.so.0(+0x7aa1)[0x7f490513daa1] 
/lib64/libc.so.6(clone+0x6d)[0x7f4904aa693d] 

Regression link: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/18986/consoleFull
 

Can you please take a look into it? 

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

[Gluster-devel] Regression: Spurious failure in arbiter.t

[Poornima Gurusiddaiah]

Hi, 

Arbiter test, ./tests/basic/afr/arbiter.t has failed for many regression runs.

./tests/basic/afr/arbiter.t (Wstat: 0 Tests: 50 Failed: 3)
  Failed tests:  22, 25, 48

Regression link 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/18980/console

Can you please look into this? Should this be moved to KNOWN_ISSUE/BAD_TEST?

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

[Gluster-devel] Md-cache xattr cahing and virtual xattrs

[Poornima Gurusiddaiah]

Hi, 

As a part of md-cache improvements to cache xattrs as well: 
http://review.gluster.org/#/c/13408/ 
we now need to differentiate between virtual and non-virtual xattr. 

Unfortunately, we have no standard naming convention for virtual and on-disk 
xattr, and we cannot even change 
now, as backward compatibility will be broken. This makes negative xattr 
caching tricky on client side. 

The proposed way of xattr caching in md-cache is, to cache all on disk 
xattrs(can be optionally excluded), and in case the 
xattr is not found in the cache, its considered as ENODATA. This means, if an 
xattr is not identified as virtual xattr, it may 
get ENODATA and fail the functionality. 

To identify a virtual xattr, one solution suggested by Raghavendra G, was to 
add a dict option saying its a virtual xattr. 
To do this, we need to first categorize the existing virtual and non-virtual 
xattrs. I have created an etherpad which contains 
a list of xattrs copied from glusterfs.h. I request each component owner/others 
to add the xattrs used by their component 
@ https://public.pad.fsfe.org/p/gluster-xattr-categorization 

After the categorization is done, will send out a patch that adds a dict option 
for every internal xattr. 

Any other suggestions are welcome. 

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

Re: [Gluster-devel] Spurious failures in ec/quota.t and distribute/bug-860663.t

[Poornima Gurusiddaiah]

Thank You, have rebased the patch.

Regards,
Poornima

- Original Message -
> From: "Xavier Hernandez" <xhernan...@datalab.es>
> To: "Poornima Gurusiddaiah" <pguru...@redhat.com>, "Gluster Devel" 
> <gluster-devel@gluster.org>, "Manikandan
> Selvaganesan" <mselv...@redhat.com>, "Susant Palai" <spa...@redhat.com>, 
> "Nithya Balachandran" <nbala...@redhat.com>
> Sent: Tuesday, March 1, 2016 4:57:11 PM
> Subject: Re: [Gluster-devel] Spurious failures in ec/quota.t and 
> distribute/bug-860663.t
> 
> Hi Poornima,
> 
> On 01/03/16 12:19, Poornima Gurusiddaiah wrote:
> > Hi,
> >
> > I see these test cases failing spuriously,
> >
> > ./tests/basic/ec/quota.t Failed Tests: 1-13, 16, 18, 20, 2
> > https://build.gluster.org/job/rackspace-regression-2GB-triggered/18637/consoleFull
> 
> This is already solved by http://review.gluster.org/13446/. It has been
> merged just a couple hours ago.
> 
> Xavi
> 
> >
> > ./tests/bugs/distribute/bug-860663.t Failed Test: 13
> > https://build.gluster.org/job/rackspace-regression-2GB-triggered/18622/consoleFull
> >
> > Could any one from Quota and dht look into it?
> >
> > Regards,
> > Poornima
> >
> >
> > ___
> > Gluster-devel mailing list
> > Gluster-devel@gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
> >
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Spurious failures in ec/quota.t and distribute/bug-860663.t

[Poornima Gurusiddaiah]

Hi, 

I see these test cases failing spuriously, 

./tests/basic/ec/quota.t Failed Tests: 1-13, 16, 18, 20, 2 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/18637/consoleFull
 
./tests/bugs/distribute/bug-860663.t Failed Test: 13 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/18622/consoleFull
 

Could any one from Quota and dht look into it? 
Regards, 
Poornima 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] [Gluster-users] heal hanging

[Poornima Gurusiddaiah]

Hi, 

As mentioned glusterfs.get_real_filename getxattr is called when we need to 
check if a file(case insensitive) exists in a directory. 

You could run the following command to get to know the perf details. 
I guess you need to have debuginfo installed for this to work. 

Record perf: 
$perf record -a -g -p  -o perf-glusterfsd.data 

Generate the stat: 
perf report -g -i perf-glusterfsd.data 

Attaching perf might slow down the process further, hence recommended to use it 
in test setup. 

Regards, 
Poornima 

- Original Message -

> From: "Raghavendra Talur" <rta...@redhat.com>
> To: "Pranith Kumar Karampuri" <pkara...@redhat.com>
> Cc: "Gluster Devel" <gluster-devel@gluster.org>, "Patrick Glomski"
> <patrick.glom...@corvidtec.com>, gluster-us...@gluster.org, "David Robinson"
> <drobin...@corvidtec.com>, "Poornima Gurusiddaiah" <pguru...@redhat.com>
> Sent: Friday, January 22, 2016 8:37:50 AM
> Subject: Re: [Gluster-devel] [Gluster-users] heal hanging

> On Jan 22, 2016 7:27 AM, "Pranith Kumar Karampuri" < pkara...@redhat.com >
> wrote:
> >
> >
> >
> > On 01/22/2016 07:19 AM, Pranith Kumar Karampuri wrote:
> >>
> >>
> >>
> >> On 01/22/2016 07:13 AM, Glomski, Patrick wrote:
> >>>
> >>> We use the samba glusterfs virtual filesystem (the current version
> >>> provided on download.gluster.org ), but no windows clients connecting
> >>> directly.
> >>
> >>
> >> Hmm.. Is there a way to disable using this and check if the CPU% still
> >> increases? What getxattr of "glusterfs.get_real_filename " does
> >> is to scan the entire directory looking for strcasecmp(,
> >> ). If anything matches then it will return the
> >> . But the problem is the scan is costly. So I wonder if
> >> this is the reason for the CPU spikes.
> >
> > +Raghavendra Talur, +Poornima
> >
> > Raghavendra, Poornima,
> > When are these getxattrs triggered? Did you guys see any brick CPU spikes
> > before? I initially thought it could be because of big directory heals.
> > But this is happening even when no self-heals are required. So I had to
> > move away from that theory.

> These getxattrs are triggered when a SMB client performs a path based
> operation. It is necessary then that some client was connected.

> The last fix to go in that code for 3.6 was
> http://review.gluster.org/#/c/10403/ .

> I am not able to determine which release of 3.6 it made into. Will update.

> Also we would need version of Samba installed. Including the vfs plugin
> package.

> There is a for loop of strcmp involved here which does take a lot of CPU. It
> should be for short bursts though and is expected and harmless.

> >
> > Pranith
> >
> >>
> >> Pranith
> >>>
> >>>
> >>> On Thu, Jan 21, 2016 at 8:37 PM, Pranith Kumar Karampuri <
> >>> pkara...@redhat.com > wrote:
> >>>>
> >>>> Do you have any windows clients? I see a lot of getxattr calls for
> >>>> "glusterfs.get_real_filename" which lead to full readdirs of the
> >>>> directories on the brick.
> >>>>
> >>>> Pranith
> >>>>
> >>>> On 01/22/2016 12:51 AM, Glomski, Patrick wrote:
> >>>>>
> >>>>> Pranith, could this kind of behavior be self-inflicted by us deleting
> >>>>> files directly from the bricks? We have done that in the past to clean
> >>>>> up an issues where gluster wouldn't allow us to delete from the mount.
> >>>>>
> >>>>> If so, is it feasible to clean them up by running a search on the
> >>>>> .glusterfs directories directly and removing files with a reference
> >>>>> count of 1 that are non-zero size (or directly checking the xattrs to
> >>>>> be sure that it's not a DHT link).
> >>>>>
> >>>>> find /data/brick01a/homegfs/.glusterfs -type f -not -empty -links -2
> >>>>> -exec rm -f "{}" \;
> >>>>>
> >>>>> Is there anything I'm inherently missing with that approach that will
> >>>>> further corrupt the system?
> >>>>>
> >>>>>
> >>>>> On Thu, Jan 21, 2016 at 1:02 PM, Glomski, Patrick <
> >>>>> patrick.glom...@corvidtec.com > wrote:
> >>>>>>
> >>>>>> Load spiked again: ~1200%

[Gluster-devel] Glusterd crash in regression

[Poornima Gurusiddaiah]

Hi, 

In upstream regression, looks like the following test has caused glusterd to 
crash. 
./tests/bugs/glusterfs/bug-879490.t 

Not sure if its a known crash, here is the link to the regression links: 
https://build.gluster.org/job/rackspace-regression-2GB-triggered/17213/consoleFull
 

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

[Gluster-devel] Writing a new xlator is made a bit easier now

[Poornima Gurusiddaiah]

Hi All, 

Here is a patch http://review.gluster.org/#/c/13061/ that creates the initial 
template for any new xlator that you wish to write. 

How to use: 
$ python ./generate_xlator.py

Eg: python ./generate_xlator.py /home/u1/glusterfs/xlators/features compression 
cmpr
This command will create the following files with some initial contents like 
copyright, fops definition, header definition etc. : 
* /home/u1/glusterfs/xlators/features/compression/Makefile.am 
* /home/u1/glusterfs/xlators/features/compression/src/Makefile.am 
* /home/u1/glusterfs/xlators/features/compression/src/compression.c 
* /home/u1/glusterfs/xlators/features/compression/src/compression.h 
* /home/u1/glusterfs/xlators/features/compression/src/compression-mem-types.h 
* /home/u1/glusterfs/xlators/features/compression/src/compression-messages.h 

By default all the fops and other functions are generated, if you do not need 
to implement certain functions, delete those functions from the the file 
`config.py`. 
One can customize the fop definition by changing CBK_TEMPLATE/FOP_TEMPLATE in 
generate_xlator.py.

This is an addition to Jeff's http://review.gluster.org/#/c/9411/
Reviews are welcome.

Merry Christmas:)

Regards,
Poornima





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

Re: [Gluster-devel] libgfapi changes to add lk_owner and lease ID

[Poornima Gurusiddaiah]

Just to sum up, the proposed solutions were:
- Use compound fops
- Use client_t for storing lease id, lk owner instead of thread local storage
- Use glfd, and glfs_object to store the lease id instead of thread local 
storage
- Add new APIs to take 2 other arguments.

Using compound fops seems like a good idea, but compound fops implementation
in libgfapi is not planned as of yet for 3.8, and also even for using compound 
fops
we would anyways need new API to set the lease ID and lkowner. The compound fop
infra can provide some shared storage that is local to all the compound fops
of the same set.

As there is no, one to one mapping between client_t and the leaseid/lk_owner,
it is as good as storing in some local storage and using mutex to co-ordinte.

glfd is used to store the lease ID and lk_owner in the current patchset, this 
works
very well for Samba, but for NFS Ganesha, glfs_object is shared across clients,
hence glfs_object cannot be used to store the lease_id and lk_owner.

Adding new API makes it clean, but adds a huge overhead of maintenance and 
possible
code duplication. Replacing the existing APIs means forcing the existing 
applications
to rewrite even if they are not using lease or lock feature.
Since every API unsets the lease ID and lk_owner, there cannot be a stale
lease_id/lk_owner. Are there any other issues with using pthread local storage?
If pthread key resource usage is a problem we could replace all the key to one
gluster key and store a struct in the gluster key.

Hence, my suggestion would be to add new APIs which use thread local storage 
and once
the compound fops are implemented in libgfapi use their infra to store lease_id
and lk_owner instead of thread local storage.

Regards,
Poornima

- Original Message -
> From: "Jeff Darcy" 
> To: "Niels de Vos" , "Ira Cooper" 
> Cc: "Gluster Devel" 
> Sent: Saturday, December 5, 2015 12:04:29 AM
> Subject: Re: [Gluster-devel] libgfapi changes to add lk_owner and lease ID
> 
> 
> 
> 
> On December 4, 2015 at 8:25:10 AM, Niels de Vos (nde...@redhat.com) wrote:
> > Okay, so you meant to say that client_t "is a horror show" for this
> > particular use-case (lease_id). It indeed does not sound suitable to use
> > client_t here.
> >  
> > I'm not much of a fan for using Thread Local Storage and would prefer to
> > see a more close to atomic way like my suggestion for compound
> > procedures in an other email in this thread. Got an opinion about that?
> 
> I’m not a big fan of the thread-local storage approach either.  It could
> work OK if there was a 1:1 mapping between threads and clients, but
> AFAIK neither Samba nor Ganesha works that way.  For anything that
> doesn’t, we’re going to be making these calls *frequently* and they’re
> far from free.  Adding extra arguments to each call is a pain[1], but it
> seems preferable in this case.
> 
> [1] Yet another reason that a control-block API would have been
> preferable to a purely argument-based API, but I guess that’s water
> under the bridge.
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] compound fop design first cut

[Poornima Gurusiddaiah]

libgfapi compound fops added inline.

- Original Message -
> From: "Kotresh Hiremath Ravishankar" 
> To: "Pranith Kumar Karampuri" 
> Cc: "Gluster Devel" 
> Sent: Wednesday, December 9, 2015 2:18:47 PM
> Subject: Re: [Gluster-devel] compound fop design first cut
> 
> Geo-rep requirements inline.
> 
> Thanks and Regards,
> Kotresh H R
> 
> - Original Message -
> > From: "Pranith Kumar Karampuri" 
> > To: "Vijay Bellur" , "Jeff Darcy" ,
> > "Raghavendra Gowdappa"
> > , "Ira Cooper" 
> > Cc: "Gluster Devel" 
> > Sent: Wednesday, December 9, 2015 11:44:52 AM
> > Subject: Re: [Gluster-devel] compound fop design first cut
> > 
> > 
> > 
> > On 12/09/2015 06:37 AM, Vijay Bellur wrote:
> > > On 12/08/2015 03:45 PM, Jeff Darcy wrote:
> > >>
> > >>
> > >>
> > >> On December 8, 2015 at 12:53:04 PM, Ira Cooper (i...@redhat.com) wrote:
> > >>> Raghavendra Gowdappa writes:
> > >>> I propose that we define a "compound op" that contains ops.
> > >>>
> > >>> Within each op, there are fields that can be "inherited" from the
> > >>> previous op, via use of a sentinel value.
> > >>>
> > >>> Sentinel is -1, for all of these examples.
> > >>>
> > >>> So:
> > >>>
> > >>> LOOKUP (1, "foo") (Sets the gfid value to be picked up by
> > >>> compounding, 1
> > >>> is the root directory, as a gfid, by convention.)
> > >>> OPEN(-1, O_RDWR) (Uses the gfid value, sets the glfd compound value.)
> > >>> WRITE(-1, "foo", 3) (Uses the glfd compound value.)
> > >>> CLOSE(-1) (Uses the glfd compound value)
> > >>
> > >> So, basically, what the programming-language types would call futures
> > >> and promises.  It’s a good and well studied concept, which is necessary
> > >> to solve the second-order problem of how to specify an argument in
> > >> sub-operation N+1 that’s not known until sub-operation N completes.
> > >>
> > >> To be honest, some of the highly general approaches suggested here scare
> > >> me too.  Wrapping up the arguments for one sub-operation in xdata for
> > >> another would get pretty hairy if we ever try to go beyond two
> > >> sub-operations and have to nest sub-operation #3’s args within
> > >> sub-operation #2’s xdata which is itself encoded within sub-operation
> > >> #1’s xdata.  There’s also not much clarity about how to handle errors in
> > >> that model.  Encoding N sub-operations’ arguments in a linear structure
> > >> as Shyam proposes seems a bit cleaner that way.  If I were to continue
> > >> down that route I’d suggest just having start_compound and end-compound
> > >> fops, plus an extra field (or by-convention xdata key) that either the
> > >> client-side or server-side translator could use to build whatever
> > >> structure it wants and schedule sub-operations however it wants.
> > >>
> > >> However, I’d be even more comfortable with an even simpler approach that
> > >> avoids the need to solve what the database folks (who have dealt with
> > >> complex transactions for years) would tell us is a really hard problem.
> > >> Instead of designing for every case we can imagine, let’s design for the
> > >> cases that we know would be useful for improving performance. Open plus
> > >> read/write plus close is an obvious one.  Raghavendra mentions
> > >> create+inodelk as well.  For each of those, we can easily define a
> > >> structure that contains the necessary fields, we don’t need a
> > >> client-side translator, and the server-side translator can take care of
> > >> “forwarding” results from one sub-operation to the next.  We could even
> > >> use GF_FOP_IPC to prototype this.  If we later find that the number of
> > >> “one-off” compound requests is growing too large, then at least we’ll
> > >> have some experience to guide our design of a more general alternative.
> > >> Right now, I think we’re trying to look further ahead than we can see
> > >> clearly.
> > Yes Agree. This makes implementation on the client side simpler as well.
> > So it is welcome.
> > 
> > Just updating the solution.
> > 1) New RPCs are going to be implemented.
> > 2) client stack will use these new fops.
> > 3) On the server side we have server xlator implementing these new fops
> > to decode the RPC request then resolve_resume and
> > compound-op-receiver(Better name for this is welcome) which sends one op
> > after other and send compound fop response.
> > 
> > List of compound fops identified so far:
> > Swift/S3:
> > PUT: creat(), write()s, setxattr(), fsync(), close(), rename()
> > 
> > Dht:
> > mkdir + inodelk
> > 
> > Afr:
> > xattrop+writev, xattrop+unlock to begin with.
> 
>   Geo-rep:
>   mknod,entrylk,stat(on backend gfid)
>   mkdir,entrylk,stat (on backend gfid)
>   symlink,entrylk,stat(on backend gfid)
>   
libgfapi :
glfs_setfsuid, glfs_setfsgid, glfs_setfsgroups, glfs_set_lkowner and 
leaseid - these are not 

Re: [Gluster-devel] libgfapi compound operations - multiple writes

[Poornima Gurusiddaiah]

Answers inline.

Regards,
Poornima

- Original Message -
> From: "Raghavendra Gowdappa" <rgowd...@redhat.com>
> To: "Poornima Gurusiddaiah" <pguru...@redhat.com>
> Cc: "Gluster Devel" <gluster-devel@gluster.org>
> Sent: Wednesday, December 9, 2015 9:00:55 PM
> Subject: libgfapi compound operations - multiple writes
> 
> forking off since it muddles the original conversation. I've some questions:
> 
> 1. Why do multiple writes need to be compounded together?
If the application splits the large write into fixed sized chunks (Samba 64KB), 
it would be an option to compound it.

> 2. If the reason is aggregation, cant we tune write-behind to do the same?
Yes surely. IO-cache would be a better candidate? write behind mostly doesn't 
aggregate.
Since this can also be one by compound fops, just added as good to have. But 
not mandatory as it can be achieved otherwise.

> 
> regards,
> Raghavendra.
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] libgfapi changes to add lk_owner and lease ID

[Poornima Gurusiddaiah]

Hi, 

Brief Background: 
 
For the below two features, we need ligfapi to take 2 other parameters from the 
applications for most number of fops. 
http://review.gluster.org/#/c/12014/ 
http://review.gluster.org/#/c/11980/ 

For leases to work as explained in the above doc, every file data read/write 
fop needs to be associated with a lease ID. This is specially required for 
Samba and NFS-Ganesha as they inturn serve other clients who request for 
leases. For Gluster to identify the end client (which is not Samba/NFS Ganesha) 
we need lease ID to be filled by Samba/NFS Ganesha. 

For mandatory locks feature to work as explained, every file data read/write 
fop needs to be associated with a lk_owner. In linux Kernel VFS takes care of 
filling the lk_ownere for the file system. In libgfapi case, the applications 
calling into libgfapi should be providing lk_owner with every fop. This is 
again required mainly for Samba and NFS Ganesha, as they serve multiple 
clients. 

Possible solutions: 
= 
1. Modify all the required APIs to take 2 other parameter, lease ID and 
lk_owner. But that would mean backward compatibility issues and is a 
programming overhead for applications not interested in Leases and mandatory 
lock feature. 
2. Add an API called glfs_set_fop_attrs (lease ID, lk_owner) which works 
similar to glfs_set_uid(uid). The API sets a thread local storage (pthread_key) 
with the values provided, the further fops on that thread will pick the lease 
ID and lk_owner from the thread local storage (pthread_key). There are few 
minor details that needs to be worked out: 
- In case of async API will end up using lease ID and lk_owner from wrong 
thread. 
- unset lease ID and lk_owner after every fop to ensure there is no stale lease 
ID or lk_owner set? 
- For fd based fops we can store the lease ID and lk_owner in glfd, so that the 
application writed need not set it for every fop. But for handle based fops 
lease ID and lk_owner needs to be set explicitly every-time. 

Solution 2 is more preferable except for that it adds overhead of calling 
another API, for the libgfapi users who intends to use these features. 
A prototype of solution 2 can be found at http://review.gluster.org/#/c/12876/ 

Please let me know if you have any suggestions. 

Thanks, 
Poorninma 

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

[Gluster-devel] Backporting libgfapi patch that frees resources

[Poornima Gurusiddaiah]

Hi, 

There were few requests from the community for backporting the fix for 
BZ:1134050 to 3.6 and 3.5. 
It requires considerable effort (~2-3 weeks) and review. I have updated the BZ 
with the link to all the patches 
that needs to be backported, please let me know if anybody is interested and 
can spend your bandwidth on this. 

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

Re: [Gluster-devel] Lease-lock Design notes

[Poornima Gurusiddaiah]

Hi Shyam, 

Please find my reply inline.

Rgards,
Poornima

- Original Message -
 From: Ira Cooper icoo...@redhat.com
 To: Shyam srang...@redhat.com
 Cc: Gluster Devel gluster-devel@gluster.org
 Sent: Saturday, July 18, 2015 4:09:30 AM
 Subject: Re: [Gluster-devel] Lease-lock Design notes
 
 1. Yes, it is intentional.  The internals of gluster should be able to
 lease-lks.  We discussed using them in the read ahead translator and the
 write behind translator.
 2. This has been discussed, and proposed, but there is actually a need for a
 lease fop also, because clients can request the renewal or reinstatement
 of a lease.  (Actually for Samba having it all be one call and atomic is
 very interesting.)
 3. This I can't answer... I haven't been in the most recent discussions.  But
 the intent of this work, when I started, was to be useful to the whole of
 Gluster, not just Samba or Ganesha.
 
 Thanks,
 
 -Ira
 
 - Original Message -
  Hi,
  
  I have some questions or gaps in understanding the current lease design,
  request some clarification on the same.
  
  1) Is there a notion of a *gluster* client holding a lease on a file/dir?
Yes, a lease is granted to a gluster client on a file, dir is not yet 
implemented, but is on cards.
The lease can be requestd from any xlator, and is granted for the whole client.

  - As per your Barcelona gluster summit presentation the client side
  caching needs this notion
  - DHT/EC/AFR can leverage such a lease to prevent eager or any form of
  locking when attempting to hold consistency of data being operated on
 - Please note that this requires not each xlator requesting and
  holding the lease, but a *gluster* client holding the lease, assuming
  that one can do local in memory locking to prevent different
  fd/connection/applications performing operations on the same file
  against the *same* gluster client and not have to coordinate this with
  the brick
  
  I see some references to this in the design but wanted to understand if
  the thought is there.
The initial thought of having leases in Gluster was to support Multiprotocol 
access,
aprt from this another use case we saw was, having a Gluster client cache xlator
which caches taking leases. Yes, DHT/EC/AFR also could leverage leases, but i m 
not
sure if leases can replace eager locks.

  
  IOW, if an NFS client requests a lease, Ganesha requests the lease from
  Gluster, in which case the gfapi client that requested the lease first
  gets the lease, and then re-leases it to Ganesha, now Ganesha is free to
  lease it to any client on its behalf and recall leases etc. as the case
  may be and the gluster client does not care. When another gluster client
  (due to Ganesha or otherwise (say self heal or rebalance)) attempts to
  get a lease, that is when the lease is broken all across.
  
  Is my understanding right, is the design along these lines?
Yes, that is right, any conflicts between its(ganesha/Samba) clients should be
resolved by the Ganesha/Samba server. Gluster server will handle the conflicts
across gluster clients.

  
  2) Why is the lease not piggy backed with the open? Why 2 network FOPs
  instead of 1 in this case? How can we compound this lease with other
  requests? Or do you have thoughts around the same?
  
  Isn't NFS and SMB requesting leases with its open calls
Our initial thought was to overload lk call to request for lease, and also
support open+lease. But the problems with fd based leases were:
 - Doesn't go well with the NFS world, where handles are created and
   delegations are granted followed by multiple open/read/write/close
   on that fd. Hence lease is more conveniently associated with handles
   than fds, in NFS.
 - Anonymous fds are used by NFSV3 and pnfs to maintain statelessness,
   aonymous fds means there is no open fd on the file, the backend opens
   read/writes to the file and closes. These anonfds makes it harder to get
   the lease conflict check right, and we may break leases when it is not
   necessary.
 - The lease might have to live longer than fd (handle based leases, i.e.
   when persistent/durable handles will be used instead of fd).
That said, we could even now overload open call to request for lease,
but it will be associated with the inode and the client and not the fd,
for the above said reasons.

  
  3) If there were discussions around some designs that were rejected,
  could you also update the document with the same, so the one can
  understand the motivation behind the current manner of implementing leases.
Yes sure, we are updating the leases.md, will send it at the earliest.

  
  Thanks,
  Shyam
  
  On 04/16/2015 07:37 AM, Soumya Koduri wrote:
   Hi,
  
   Below link contains the lease-lock design notes (as per the latest
   discussion we had). Thanks to everyone involved (CC'ed).
  
   http://www.gluster.org/community/documentation/index.php/Features/Upcall-infrastructure#delegations.2Flease-locks
  
  
   Kindly go through the 

Re: [Gluster-devel] Gluster Coreutils

[Poornima Gurusiddaiah]

Hi Craig,

That's cool! I was more interested in knowing how you plan to implement the 
commands.
To be specific, do you plan to connect/disconnect(glfs_init/glfs_fini) to the 
gluster
server for each command or persist the connection across commands?

Regards,
Poornima

- Original Message -
 From: Craig Cabrey craigcab...@fb.com
 To: Joe Julian j...@julianfamily.org
 Cc: gluster-devel@gluster.org
 Sent: Monday, June 15, 2015 3:19:07 AM
 Subject: Re: [Gluster-devel] Gluster Coreutils
 
 I've already started writing the utilities in C per my internship project.
 I'll push these up when ready (most probably sometime this week) as a POC.
 
 Maybe then we can look into implementing with Python?
 
 Craig
 
  On Jun 14, 2015, at 2:47 PM, Joe Julian j...@julianfamily.org wrote:
  
  I was thinking the other way around. Write it in python then optimize if
  it's necessary.
  On 06/14/2015 02:45 PM, chris holcombe wrote:
  Maybe we could write these in C and setup python bindings for them.
  Thoughts?  I'm down with writing them in C.  I could use more practice.
  
  On 06/14/2015 02:36 PM, Joe Julian wrote:
  I would prefer python.
  
  On 06/14/2015 11:18 AM, Niels de Vos wrote:
  On Sat, Jun 13, 2015 at 06:45:45PM +0530, M S Vishwanath Bhat wrote:
  On 12 June 2015 at 23:59, chris holcombe chris.holco...@canonical.com
  wrote:
  
  Yeah I have this repo but it's basically empty:
  https://github.com/cholcombe973/GlusterUtils
  
  AFAIK the plan is to collaborate through a git repo in
  github.com/gluster
  account. But anything that works should be good...
  
  And the choice of language seems to be python.
  Depending on the target systems, Python may not be suitable. There are
  cloud deployments that do not have Python installed. I think that even
  includes the minimal cloud images Fedora and CentOS provide. IMHO would
  be nice to be able to support those systems too, without pulling in too
  many dependencies.
  
  But, I'll leave it up to the people writing the code ;-)
  
  Cheers,
  Niels
  
  Best Regards,
  Vishwanath
  
  
  On 06/12/2015 11:27 AM, Craig Cabrey wrote:
  
  Chris,
  
  That sounds good to me.
  
  I already have started on implementation, just to get familiar with
  the
  codebase and GFAPI.
  
  Is there a public repo that we can use for collaboration?
  
  Craig
  
   On Jun 12, 2015, at 10:46 AM, chris holcombe 
  chris.holco...@canonical.com wrote:
  
  Craig,
  
  I was actually planning on building the same tool set. I would like
  to
  work with you also on this if that's ok.
  
  -Chris
  
  On 06/12/2015 10:43 AM, Jeff Darcy wrote:
  
  Hi everyone,
  This summer I am an intern at Facebook working on the Gluster
  team.
  Part of
  my project for the summer includes developing a set of coreutils
  that
  utilizes the Gluster C API natively.
  
  This project is similar in nature to the NFS coreutils that some
  of
  you may
  have heard about from the other Facebook engineers at the Gluster
  summit
  recently. I just wanted to reach out to the Gluster community to
  gather
  ideas, potential features, feedback, and direction.
  
  The initial set of utilities that I am developing includes the
  following:
  
  * cat
  * mkdir
  * put (read from stdin and write to a file)
  * mv
  * ls
  * rm
  * tail
  
  Again, any feedback will be welcome.
  Hi, Craig, and welcome to the project.  :)
  
  There seems to be some overlap with a proposal Ragahavendra Talur
  sent
  out
  a couple of days ago.
  
  
  https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/document/d/1yuRLRbdccx_0V0UDAxqWbz4g983q5inuINHgM1YO040/edit?usp%3Dsharingk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=ThH6JMKaB%2Fxgkh9d2jPjehcdps8B69L0q04jdBbZvX4%3D%0Am=86la5Xg7nlxAzIR6E5c2v2SgQSd6VssYzB%2BklM3wf%2BI%3D%0As=8d55bb5770b8ed1d683a6908a05af32b79289735c537c660252fcaa7c690e162
  
  This seems like an excellent opportunity to collaborate.  Ideally,
  I
  think
  it would be useful to have both an FTP-client-like shell and a
  set of
  standalone one shot commands, based on as much common code as
  possible.
  
  ___
  Gluster-devel mailing list
  Gluster-devel@gluster.org
  
  https://urldefense.proofpoint.com/v1/url?u=http://www.gluster.org/mailman/listinfo/gluster-develk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=ThH6JMKaB%2Fxgkh9d2jPjehcdps8B69L0q04jdBbZvX4%3D%0Am=86la5Xg7nlxAzIR6E5c2v2SgQSd6VssYzB%2BklM3wf%2BI%3D%0As=28546cdc6fdf6f75f4cfa4b8260abc595eee96601a5f849ebb230ddbd1faf8b3
  ___
  Gluster-devel mailing list
  Gluster-devel@gluster.org
  https://urldefense.proofpoint.com/v1/url?u=http://www.gluster.org/mailman/listinfo/gluster-develk=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=ThH6JMKaB%2Fxgkh9d2jPjehcdps8B69L0q04jdBbZvX4%3D%0Am=vXGpsdu0VQkkhe9HG68hcfca%2F938GTXmmbz4t56hNMg%3D%0As=33c038573fdbc5f7914eefe2f0a5e8cfc57ea8c652a1cb42358e6d1a401628f1
  ___
  Gluster-devel mailing list
  

Re: [Gluster-devel] Shared resource pool for libgfapi

[Poornima Gurusiddaiah]

Initially ctx had a one to one mapping with process and volume/mount, but with 
libgfapi
and libgfchangelog, ctx has lost the one to one association with process.
The question is do we want to retain one to one mapping between ctx and process 
or
ctx and volume.

Having one ctx per process:
=== 
Shared ctx mandates that any vol specific information moves to a different
structure, as suggested glfs_t.

The complication is that currently the definition of ctx is common across
all gluster processes (cli, glusterfs, glusterfsd, gsyncd etc.). The options
are:
- To have common ctx for all gluster processes which means a new struct 
equivalent
  to glfs_t in all processes.
- To have separate definition of ctx only for libgfapi, which means changing the
  whole of the stack which references ctx, to be aware of this difference.

Or another approach will be to have libgfapi implemented in the lines of gnfs,
which ensures ctx is common for all the volumes and all the mounts.

Having one ctx per volume:
==
The problem is some of the resources like threads and mem pools should be shared
across ctxs. To deal with this, have a resource pool which provides threads and 
mem
pools, and have ctx get and put these pools.
The resulting abstract will be, common resource pool in gluster which caters to 
all
the resource requirements of the process. And the ctx will be associated with 
volume
instead of process.

The two choices are:
- Resource pool and disassociate ctx with process
- libgfapi in lines of gnfs and retain one ctx per process, but the complexity 
and the
  change involved is high.

Let us know your comments.

Regards,
Poornima


- Original Message -
 From: Vijay Bellur vbel...@redhat.com
 To: Jeff Darcy jda...@redhat.com, Poornima Gurusiddaiah 
 pguru...@redhat.com
 Cc: Gluster Devel gluster-devel@gluster.org
 Sent: Monday, June 8, 2015 11:24:38 PM
 Subject: Re: [Gluster-devel] Shared resource pool for libgfapi
 
 On 06/08/2015 05:21 PM, Jeff Darcy wrote:
  Every resource(thread, mem pools) is associated with glusterfs_ctx,
  hence as the ctxs in the process grows the resource utilization also
  grows (most of it being unused).  This mostly is an issue with any
  libgfapi application: USS, NFS Ganesha, Samba, vdsm, qemu.  It is
  normal in any of the libgfapi application to have multiple
  mounts(ctxs) in the same process, we have seen the number of threads
  scale from 10s-100s in these applications.
 
  Solution:
  ==
  Have a shared resource pool, threads and mem pools. Since they are
  shared
 
  Looking at it from a different perspective...
 
  As I understand it, the purpose of glusterfs_ctx is to be a container
  for these resources.  Therefore, the problem is not that the resources
  aren't shared within a context but that the contexts aren't shared
  among glfs objects.  This happens because we unconditionally call
  glusterfs_ctx_new from within glfs_new.  To be honest, this looks a
  bit like rushed code to me - a TODO in early development that never
  got DONE later.  Perhaps the right thing to do is to let glfs_new
  share an existing glusterfs_ctx instead of always creating a new one.
  It would even be possible to make this the default behavior (so that
  existing apps can benefit without change) but it might be better for
  it to be a new call.  As a potential future enhancement, we could
  provide granular control over which resources are shared and which
  are private, much like clone(2) does with threads.
 
 +1. In the pre gfapi days, ctx was intended to be a global resource -
 one per process and was available to all translators.  It makes sense to
 retain the same behavior in gfapi by having a single ctx that can be
 shared across multiple glfs instances.
 
 -Vijay
 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

[Gluster-devel] Shared resource pool for libgfapi

[Poornima Gurusiddaiah]

Hi, 

Every resource(thread, mem pools) is associated with glusterfs_ctx, hence as 
the ctxs in the process 
grows the resource utilization also grows (most of it being unused). This 
mostly is an issue with any 
libgfapi application: USS, NFS Ganesha, Samba, vdsm, qemu. 
It is normal in any of the libgfapi application to have multiple mounts(ctxs) 
in the same process, 
we have seen the number of threads scale from 10s-100s in these applications. 

Solution: 
== 
Have a shared resource pool, threads and mem pools. Since they are shared have 
a scaling policy that 
scales based on the number of ctxs. 

Resources that can be shared: 
- Synctask threads 
- Timer threads, circular buf timer threads 
- Sigwaiter thread 
- poller threads, these aren't as straight forward as others. If we want to 
share the poll threads, 
we will have to reuse ports which is a different topic. Hence keeping poller 
threads out of this mail as of now. 
- Mem pools: iobuf, dict, stub, frames and others 

Once it is tried and tested in libgfapi, it can be extended to other gluster 
processes. 
Initial patch for this is posted @ http://review.gluster.org/11101 

Please provide your thoughts on the same. 

Thank You, 
Poornima 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Issue with THIS and libgfapi

[Poornima Gurusiddaiah]

 
 - Original Message -
  From: Jeff Darcy jda...@redhat.com
  To: Poornima Gurusiddaiah pguru...@redhat.com
  Cc: Gluster Devel gluster-devel@gluster.org
  Sent: Wednesday, May 13, 2015 12:39:29 PM
  Subject: Re: [Gluster-devel] Issue with THIS and libgfapi
  
   Before the master xlator (fuse/libgfapi) is created, all the code that
   access
   THIS will be using global_xlator object,
   defined globally for the whole of the process.
   The problem is when multiple threads start modifying THIS, and overwrite
   thr
   global_xlators' ctx eg: glfs_new:
   glfs_new () {
   ...
   ctx = glusterfs_ctx_new();
   glusterfs_globals_inti();
   THIS = NULL; /* implies THIS = global_xlator */
   THIS-ctx = ctx;
   ...
   }
   The issue is more severe than it appears, as the other threads like
   epoll,
   timer, sigwaiter, when not executing in
   fop context will always refer to the global_xlator and
   global_xlator-ctx.
   Because of the probable race condition
   explained above we may be referring to the stale ctxs and could lead to
   crashes.
  
  Is it not true that we *want* multiple threads to share some of these data
  structures?  For example, it seems like multiple epoll threads should be
  operating on the same set of file descriptors and so on; they just need to
  do so in a controlled way.
 
 AFAIK, THIS was/is a convenient way of accessing xlator object in whose
 context we are executing (instead of passing down it as an argument in every
 function in the call stack). Going by this requirement, its unlikely that we
 want multiple threads share THIS. However, I am not very clear on the
 purpose of having THIS pointing to global xlator when we are not executing
 in any xlator context.

The purpose of global_xlator:
- To be used (mostly for mem accnt) before the master xlator(gfapi/Fuse) is 
created
- Gives the current ctx, it is executing as a part of
- To be used by the epoll and other threads to account memory for
  non fop functions like the mgmt functions etc.

 
  If that's the case, then it's not clear that
  having per-thread global_xlator objects will really work.  Am I not
  correctly understanding the nature of the problem?
  

Yes multiple threads need to share some of the data structures.
And global_xlator should be shared across threads, the problem explained above 
is when it is shared across multiple glusterfs_ctxs. In this case global_xlator
may point to the stale ctx instead of current ctx.

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

[Gluster-devel] Issue with THIS and libgfapi

[Poornima Gurusiddaiah]

Hi, 

We recently uncovered an issue with THIS and libgfapi, it can be generalized to 
any process having multiple glusterfs_ctxs. 

Before the master xlator (fuse/libgfapi) is created, all the code that access 
THIS will be using global_xlator object, 
defined globally for the whole of the process. 
The problem is when multiple threads start modifying THIS, and overwrite thr 
global_xlators' ctx eg: glfs_new: 
glfs_new () { 
... 
ctx = glusterfs_ctx_new(); 
glusterfs_globals_inti(); 
THIS = NULL; /* implies THIS = global_xlator */ 
THIS-ctx = ctx; 
... 
} 
The issue is more severe than it appears, as the other threads like epoll, 
timer, sigwaiter, when not executing in 
fop context will always refer to the global_xlator and global_xlator-ctx. 
Because of the probable race condition 
explained above we may be referring to the stale ctxs and could lead to 
crashes. 

Probable solution: 
Currently THIS is thread specific, but the global xlator object it modifies is 
global to all threads!! 
The obvious association would be to have global_xlator per ctx instead of per 
process. 
The changes would be as follows: 
- Have a new global_xlator object in glusterfs_ctx. 
- After every creation of new ctx assign 
store THIS 
THIS = new_ctx-global_xlator 
restore THIS 
- But how to set the THIS in every thread(epoll, timer etc) that gets created 
as a part of that ctx. 
Replace all the pthread_create for the ctx threads, with gf_pthread_create: 
gf_pthread_create (fn,..., ctx) { 
... 
thr_id = pthread_create (global_thread_init, fn, ctx...); 
... 
} 

global_thread_init (fn, ctx, args) { 
THIS = ctx-global_xlator; 
fn(args); 
} 

The other solution would be to not associate threads with ctx, instead shared 
among ctxs 

Please let me know your thoughts on the same. 

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

[Gluster-devel] libgfapi usage issues: overwrites 'THIS' and use after free

[Poornima Gurusiddaiah]

Hi, 

There are two concerns in the usage of libgfapi which have been present from 
day one, but now 
with new users of libgfapi its a necessity to fix these: 

1. When libgfapi is used by the GlusterFS internal xlators, 'THIS' gets 
overwritten: 
Eg: when snapview-server creates a new fs instance for every snap that is 
created. 
Currently any libgfapi calls inside the xlator overwrites the THIS value to 
contain glfs-master(gfapi xlator). 
Hence after the api exits, any further code in the parent xlator referring to 
THIS will refer 
to the glfs-master(gfapi xlator). 

Proposed solutions: 
- Store and restore THIS in every API exposed by libgfapi, patch for the same 
can be found at http://review.gluster.org/#/c/9797/ 
- Other solution suggested by Niels was to not have internal xlators calling 
libgfapi and 
move the core functionality to libglusterfs. But even with this the nested 
mount/ctx issue can still exist. 

2. When libgfapi APIs are called by the application on a fs object, that is 
already closed(glfs_fini()'ed): 
Ideally it is the applications responsibility to take care, to not do such 
things. But its also good 
to not crash libgfapi when such ops are performed by the application. 
We have already seen these issues in snapview server. 

Proposed Solutions/workarounds: 
- Do not free the fs object(leaks few bytes) have a state bit to say valid or 
invalid. In every API check 
for the fs validity before proceeding. Patch for same 
@http://review.gluster.org/#/c/9797/ 
- As suggested by Niels, have a fs global pool which tracks allocated/freed fs 
objects. 
- Have the applications fix it, so that they do not call fops on closed fs 
object(unmounted fs). 
This mandates multithreaded/asynchronous applications to have some 
synchronization mechanism. 

Please let me know your comments on the same. 

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

Re: [Gluster-devel] Spurious failure report for master branch - 2015-03-03

[Poornima Gurusiddaiah]

Few more test cases causing spurious failures:

./tests/basic/ec/ec-5-1.t 
Failed test:  69

./tests/basic/ec/ec-5-2.t
Failed test:  69

./tests/bugs/disperse/bug-1187474.t
 Failed tests:  11-12

./tests/basic/ec/nfs.t
 Failed test:  9

The above failures were seen for the patches which were ineffective,
i.e. the code that was modified was never executed as it had no callers.

Regards,
Poornima

- Original Message -
 From: Justin Clift jus...@gluster.org
 To: Gluster Devel gluster-devel@gluster.org
 Sent: Wednesday, March 4, 2015 9:57:00 AM
 Subject: [Gluster-devel] Spurious failure report for master branch -  
 2015-03-03
 
 Ran 20 x regression tests on our GlusterFS master branch code
 as of a few hours ago, commit 95d5e60afb29aedc29909340e7564d54a6a247c2.
 
 5 of them were successful (25%), 15 of them failed in various ways
 (75%).
 
 We need to get this down to about 5% or less (preferably 0%), as it's
 killing our development iteration speed.  We're wasting huge amounts
 of time working around this. :(
 
 
 Spurious failures
 *
 
   * 5 x tests/bugs/distribute/bug-1117851.t
   (Wstat: 0 Tests: 24 Failed:
   1)
 Failed test:  15
 
 This one is causing a 25% failure rate all by itself. :(
 
 This needs fixing soon. :)
 
 
   * 3 x tests/bugs/geo-replication/bug-877293.t
   (Wstat: 0 Tests: 15 Failed: 1)
 Failed test:  11
 
   * 2 x tests/basic/afr/entry-self-heal.t
   (Wstat: 0 Tests: 180
   Failed: 2)
 Failed tests:  127-128
 
   * 1 x tests/basic/ec/ec-12-4.t
   (Wstat: 0 Tests:
   541 Failed: 2)
 Failed tests:  409, 441
 
   * 1 x tests/basic/fops-sanity.t
   (Wstat: 0 Tests:
   11 Failed: 1)
 Failed test:  10
 
   * 1 x tests/basic/uss.t
   (Wstat: 0
   Tests: 160 Failed: 1)
 Failed test:  26
 
   * 1 x tests/performance/open-behind.t
   (Wstat: 0 Tests: 17
   Failed: 1)
 Failed test:  17
 
   * 1 x tests/bugs/distribute/bug-884455.t
   (Wstat: 0 Tests: 22 Failed:
   1)
 Failed test:  11
 
   * 1 x tests/bugs/fuse/bug-1126048.t
   (Wstat: 0 Tests: 12
   Failed: 1)
 Failed test:  10
 
   * 1 x tests/bugs/quota/bug-1038598.t
   (Wstat: 0 Tests: 28
   Failed: 1)
 Failed test:  28
 
 
 2 x Coredumps
 *
 
   * http://mirror.salasaga.org/gluster/master/2015-03-03/bulk5/
 
 IP - 104.130.74.142
 
 This coredump run also failed on:
 
   * tests/basic/fops-sanity.t
   (Wstat: 0
   Tests: 11 Failed: 1)
 Failed test:  10
 
   * tests/bugs/glusterfs-server/bug-861542.t
   (Wstat: 0 Tests: 13 Failed:
   1)
 Failed test:  10
 
   * tests/performance/open-behind.t
   (Wstat: 0 Tests: 17
   Failed: 1)
 Failed test:  17
 
   * http://mirror.salasaga.org/gluster/master/2015-03-03/bulk8/
 
 IP - 104.130.74.143
 
 This coredump run also failed on:
 
   * tests/basic/afr/entry-self-heal.t
   (Wstat: 0 Tests: 180
   Failed: 2)
 Failed tests:  127-128
 
   * tests/bugs/glusterfs-server/bug-861542.t
   (Wstat: 0 Tests: 13 Failed:
   1)
 Failed test:  10
 
 Both VMs are also online, in case they're useful to log into
 for investigation (root / the jenkins slave pw).
 
 If they're not, please let me know so I can blow them away. :)
 
 
 1 x hung host
 *
 
 Hung on tests/bugs/posix/bug-1113960.t
 
 root  12497  1290  0 Mar03 ?  S  0:00  \_ /bin/bash /opt/qa/regression.sh
 root  12504 12497  0 Mar03 ?  S  0:00  \_ /bin/bash ./run-tests.sh
 root  12519 12504  0 Mar03 ?  S  0:03  \_ /usr/bin/perl
 /usr/bin/prove -rf --timer ./tests
 root  22018 12519  0 00:17 ?  S  0:00  \_ /bin/bash
 ./tests/bugs/posix/bug-1113960.t
 root  30002 22018  0 01:57 ?  S  0:00  \_ mv
 /mnt/glusterfs/0/longernamedir1/longernamedir2/longernamedir3/
 
 This VM (23.253.53.111) is still online + untouched (still hung),
 if someone wants to log in to investigate.  (root / the jenkins
 slave pw)
 
 Hope that's helpful. :)
 
 Regards and best wishes,
 
 Justin Clift
 
 --
 GlusterFS - http://www.gluster.org
 
 An open source, distributed file system scaling to several
 petabytes, and handling thousands of clients.
 
 My personal twitter: twitter.com/realjustinclift
 
 ___
 Gluster-devel mailing list
 Gluster-devel@gluster.org
 http://www.gluster.org/mailman/listinfo/gluster-devel
 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Appending time to snap name in USS

[Poornima Gurusiddaiah]

Yes, the creation time of the snap is appended to the snapname dynamically, 
i.e. snapview-server takes the snaplist from glusterd, and while populating the 
dentry for the .snaps it appends the time. 

Thanks, 
Poornima 

- Original Message -

 From: Anand Avati av...@gluster.org
 To: Poornima Gurusiddaiah pguru...@redhat.com, Gluster Devel
 gluster-devel@gluster.org, gluster-users gluster-us...@gluster.org
 Sent: Friday, January 9, 2015 1:49:02 AM
 Subject: Re: [Gluster-devel] Appending time to snap name in USS

 It would be convenient if the time is appended to the snap name on the fly
 (when receiving list of snap names from glusterd?) so that the timezone
 application can be dynamic (which is what users would expect).

 Thanks

 On Thu Jan 08 2015 at 3:21:15 AM Poornima Gurusiddaiah  pguru...@redhat.com
  wrote:

  Hi,
 

  Windows has a feature called shadow copy. This is widely used by all
 
  windows users to view the previous versions of a file.
 
  For shadow copy to work with glusterfs backend, the problem was that
 
  the clients expect snapshots to contain some format
 
  of time in their name.
 

  After evaluating the possible ways(asking the user to create
 
  snapshot with some format of time in it and have rename snapshot
 
  for existing snapshots) the following method seemed simpler.
 

  If the USS is enabled, then the creation time of the snapshot is
 
  appended to the snapname and is listed in the .snaps directory.
 
  The actual name of the snapshot is left unmodified. i.e. the snapshot
 
  list/info/restore etc. commands work with the original snapname.
 
  The patch for the same can be found @ http://review.gluster.org/#/c/9371/
 

  The impact is that, the users would see the snapnames to be different in
  the
  .snaps folder
 
  than what they have created. Also the current patch does not take care of
  the
  scenario where
 
  the snapname already has time in its name.
 

  Eg:
 
  Without this patch:
 
  drwxr-xr-x 4 root root 110 Dec 26 04:14 snap1
 
  drwxr-xr-x 4 root root 110 Dec 26 04:14 snap2
 

  With this patch
 
  drwxr-xr-x 4 root root 110 Dec 26 04:14 snap1@GMT-2014.12.30-05.07.50
 
  drwxr-xr-x 4 root root 110 Dec 26 04:14 snap2@GMT-2014.12.30-23.49.02
 

  Please let me know if you have any suggestions or concerns on the same.
 

  Thanks,
 
  Poornima
 
  __ _
 
  Gluster-devel mailing list
 
  Gluster-devel@gluster.org
 
  http://www.gluster.org/ mailman/listinfo/gluster-devel
 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Unable to start samba service (smb) - due to /run/samba/ncalrpc - No such file or directory

[Poornima Gurusiddaiah]

Hi, 

Can you post the output of #strace smbd and the logs(log.smbd) 
Was it an upgrade from older samba version? If yes, try clearing the 
/var/lib/samba/*.tdb files. 

Regards, 
Poornima 

- Original Message -

 From: Omkar Sharma om...@fractalio.com
 To: gluster-devel@gluster.org
 Sent: Thursday, December 25, 2014 3:17:44 PM
 Subject: [Gluster-devel] Unable to start samba service (smb) - due to
 /run/samba/ncalrpc - No such file or directory

 Hi,

 I have installed samba-4.1.11-2.el6.x86_64.rpm and its dependencies taken
 from the below link:

 http://download.gluster.org/pub/gluster/glusterfs/samba/CentOS/epel-6.5/x86_64/

 The samba package got installed but unable to start the smb service. And I
 have smb file inside /etc/init.d/ directory.

 $ sudo service smb status ...not showing any output
 $ sudo service smb start ...not showing any output

 $ sudo /etc/init.d/smb status ...not showing any output
 $ sudo /etc/init.d/smb start ...not showing any output

 And I went to see the log files inside /var/log/samba/.

 $ vi /var/log/samba/log.smbd

 smbd version 4.1.11 started.
 Copyright Andrew Tridgell and the Samba Team 1992-2013
 [2014/12/24 06:36:44.225371, 0] ../source3/smbd/server.c:1289(main)
 standard input is not a socket, assuming -D option
 [2014/12/24 06:36:44.472002, 0]
 ../lib/util/util.c:216(directory_create_or_exist)
 mkdir failed on directory /run/samba/ncalrpc: No such file or directory
 [2014/12/24 06:36:44.472317, 0] ../source3/smbd/server.c:1471(main)
 Failed to create pipe directory /run/samba/ncalrpc - No such file or
 directory

 Why the samba rpm is not creating /run/samba directory and place the file
 ncalrpc ?

 With Regards,
 Omkar MN

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

Re: [Gluster-devel] EHT / DHT

[Poornima Gurusiddaiah]

Out of curiosity, what back end and deduplication solution are you using? 

Regards, 
Poornima 

- Original Message -

From: Jan H Holtzhausen j...@holtztech.info 
To: Anand Avati av...@gluster.org, Shyam srang...@redhat.com, 
gluster-devel@gluster.org 
Sent: Wednesday, November 26, 2014 3:43:36 AM 
Subject: Re: [Gluster-devel] EHT / DHT 

Yes we have deduplication at the filesystem layer 

BR 
Jan 

From: Anand Avati  av...@gluster.org  
Date: Wednesday 26 November 2014 at 12:11 AM 
To: Jan H Holtzhausen  j...@holtztech.info , Shyam  srang...@redhat.com ,  
gluster-devel@gluster.org  
Subject: Re: [Gluster-devel] EHT / DHT 

Unless there is some sort of de-duplication under the covers happening in the 
brick, or the files are hardlinks to each other, there is no cache benefit 
whatsoever by having identical files placed on the same server. 

Thanks, 
Avati 

On Tue Nov 25 2014 at 12:59:25 PM Jan H Holtzhausen  j...@holtztech.info  
wrote: 


As to the why. 
Filesystem cache hits. 
Files with the same name tend to be the same files. 

Regards 
Jan 




On 2014/11/25, 8:42 PM, Jan H Holtzhausen  j...@holtztech.info  wrote: 

So in a distributed cluster, the GFID tells all bricks what a files 
preceding directory structure looks like? 
Where the physical file is saved is a function of the filename ONLY. 
Therefore My requirement should be met by default, or am I being dense? 
 
BR 
Jan 
 
 
 
On 2014/11/25, 8:15 PM, Shyam  srang...@redhat.com  wrote: 
 
On 11/25/2014 03:11 PM, Jan H Holtzhausen wrote: 
 STILL doesn’t work … exact same file ends up on 2 different bricks … 
 I must be missing something. 
 All I need is for: 
 /directory1/subdirectory2/foo 
 And 
 /directory2/ subdirectoryaaa999/foo 
 
 
 To end up on the same brick…. 
 
This is not possible is what I was attempting to state in the previous 
mail. The regex filter is not for this purpose. 
 
The hash is always based on the name of the file, but the location is 
based on the distribution/layout of the directory, which is different 
for each directory based on its GFID. 
 
So there are no options in the code to enable what you seek at present. 
 
Why is this needed? 
 
Shyam 
 
_ __ 
Gluster-devel mailing list 
 Gluster-devel@gluster.org 
 http://supercolony.gluster. org/mailman/listinfo/gluster- devel 

__ _ 
Gluster-devel mailing list 
Gluster-devel@gluster.org 
http://supercolony.gluster. org/mailman/listinfo/gluster- devel 




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

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