Re: [Gluster-devel] Spurious termination of fuse invalidation notifier thread

2016-09-05 Thread Xavier Hernandez 

Hi Raghavendra,

On 03/09/16 05:42, Raghavendra Gowdappa wrote:

Hi Xavi/Kaleb/Pranith,

During few of our older conversations (like [1], but not only one), some of you 
had reported that the thread which writes invalidation notifications (of 
inodes, entries) to /dev/fuse terminates spuriously. Csaba tried to reproduce 
the issue, but without success. It would be helpful if you provide any 
information on reproducer and/or possible reasons for the behavior.


I didn't found what really caused the problem. I only saw the 
termination message on a production server after some days working but 
hadn't had the opportunity to debug it.


Looking at the code, the only conclusion I got is that the result from 
the write to /dev/fuse was unexpected. The patch solves this and I 
haven't seen the problem again.


The old code only manages ENOENT error. It exits the thread for any 
other error. I guess that in some situations a write to /dev/fuse can 
return other "non fatal" errors.


As a guess, I think it may be a failure in an entry invalidation. 
Looking at the code of fuse, it may return ENOTDIR if parent of the 
entry is not a directory and some race happens doing rm/create while 
sending invalidations in the background. Another possibility is 
ENOTEMPTY if the entry references a non empty directory (again probably 
caused by races between user mode operations and background 
invalidations). Anyway this is only a guess, I have no more information.


Xavi



[1] http://review.gluster.org/#/c/13274/1/xlators/mount/fuse/src/fuse-bridge.c

regards,
Raghavendra


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

Re: [Gluster-devel] Checklist for gfapi for upstream release

2016-09-05 Thread Niels de Vos 
On Sat, Sep 03, 2016 at 12:10:41AM +0530, Pranith Kumar Karampuri wrote:
> hi,
> I think most of this testing will be covered in nfsv4, smb testing.
> But I could be wrong. Could you let me know who will be providing with the
> list if you think there are more tests that need to be run?
> 
> I can update it at https://public.pad.fsfe.org/p/
> gluster-component-release-checklist

I've added this to the etherpad:

> test known applications, run their test-suites:
> glusterfs-coreutils (has test suite in repo)
> libgfapi-python (has test suite in repo)
> nfs-ganesha (pynfs and cthon04 tests)
> Samba (test?)
> QEMU (run qemu binary and qemu-img with gluster:// URL, possibly/somehow 
> run Advocado suite)

Niels


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

Re: [Gluster-devel] Checklist for QEMU integration for upstream release

2016-09-05 Thread Niels de Vos 
On Sat, Sep 03, 2016 at 01:04:37AM +0530, Pranith Kumar Karampuri wrote:
> hi Bharata,
>What tests are run before the release of glusterfs so that we make
> sure this integration is stable? Could you add that information here so
> that I can update it at
> https://public.pad.fsfe.org/p/gluster-component-release-checklist

I normally run some qemu-img commands to create/copy/... VM-images. When
I have sufficient time, I start a VM based on a gluster:// URL on the
commandline (through libvirt XML files), similar to this:
  http://blog.nixpanic.net/2013/11/initial-work-on-gluster-integration.html

In case Bharata is not actively working (or interested) in QEMU and it's
Gluster driver, Prasanna and I should probably replace or get added in
the MAINTAINERS file, both of us get requests from the QEMU maintainers
directly.

Niels


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

Re: [Gluster-devel] Checklist for snapshot component for upstream release

2016-09-05 Thread Avra Sengupta 

Hi Pranith,

The following set of automated and manual tests need to pass before 
doing a release for snapshot component:
1. The entire snapshot regression suite present in the source 
repository, which as of now consist of:


   a. ./basic/volume-snapshot.t
   b. ./basic/volume-snapshot-clone.t
   c. ./basic/volume-snapshot-xml.t
   d. All tests present in ./bugs/snapshot

2. Manual test of using snapshot scheduler.
3. Till the eventing test framework is integrated with the regression 
suite, manual test of all 28 snapshot events.


Regards,
Avra

On 09/03/2016 12:26 AM, Pranith Kumar Karampuri wrote:

hi,
Did you get a chance to decide on the tests that need to be 
done before doing a release for snapshot component? Could you let me 
know who will be providing with the list?


I can update it at 
https://public.pad.fsfe.org/p/gluster-component-release-checklist 



--
Aravinda & Pranith


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

Re: [Gluster-devel] Spurious termination of fuse invalidation notifier thread

2016-09-05 Thread Raghavendra Gowdappa 


- Original Message -
> From: "Xavier Hernandez" 
> To: "Raghavendra Gowdappa" , "Kaleb Keithley" 
> , "Pranith Kumar Karampuri"
> 
> Cc: "Csaba Henk" , "Gluster Devel" 
> 
> Sent: Monday, September 5, 2016 12:46:43 PM
> Subject: Re: Spurious termination of fuse invalidation notifier thread
> 
> Hi Raghavendra,
> 
> On 03/09/16 05:42, Raghavendra Gowdappa wrote:
> > Hi Xavi/Kaleb/Pranith,
> >
> > During few of our older conversations (like [1], but not only one), some of
> > you had reported that the thread which writes invalidation notifications
> > (of inodes, entries) to /dev/fuse terminates spuriously. Csaba tried to
> > reproduce the issue, but without success. It would be helpful if you
> > provide any information on reproducer and/or possible reasons for the
> > behavior.
> 
> I didn't found what really caused the problem. I only saw the
> termination message on a production server after some days working but
> hadn't had the opportunity to debug it.
> 
> Looking at the code, the only conclusion I got is that the result from
> the write to /dev/fuse was unexpected. The patch solves this and I
> haven't seen the problem again.
> 
> The old code only manages ENOENT error. It exits the thread for any
> other error. I guess that in some situations a write to /dev/fuse can
> return other "non fatal" errors.

Thanks Xavi. Now I remember the changes. Since you have not seen spurious 
termination after the changes, I assume the issue is fixed.

> 
> As a guess, I think it may be a failure in an entry invalidation.
> Looking at the code of fuse, it may return ENOTDIR if parent of the
> entry is not a directory and some race happens doing rm/create while
> sending invalidations in the background. Another possibility is
> ENOTEMPTY if the entry references a non empty directory (again probably
> caused by races between user mode operations and background
> invalidations). Anyway this is only a guess, I have no more information.
> 
> Xavi
> 
> >
> > [1]
> > http://review.gluster.org/#/c/13274/1/xlators/mount/fuse/src/fuse-bridge.c
> >
> > regards,
> > Raghavendra
> >
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] How to enable FUSE kernel cache about dentry and inode?

2016-09-05 Thread Ravishankar N 
That is strange. I tried the experiment on a volume with a million 
files. The client node's memory usage did grow, as I observed from the 
output of free(1) http://paste.fedoraproject.org/422551/ when I did a `ls`.

-Ravi

On 09/02/2016 07:31 AM, Keiviw wrote:
Exactly, I mounted the volume in a no-brick node(nodeB), and nodeA was 
the server. I have set different timeout, but when I excute "ls 
/mnt/glusterfs(about 3 million small files, in other words, about 3 
million dentries)", the result was the same, memory usage in nodeB 
didn't change at all while nodeA's memory usage was changed about 4GB!


发自 网易邮箱大师 
On 09/02/2016 09:45, Ravishankar N  wrote:

On 09/02/2016 05:42 AM, Keiviw wrote:

Even if I set the attribute-timeout and entry-timeout to
3600s(1h), in the nodeB, it didn't cache any metadata because the
memory usage didn't change. So I was confused that why did the
client not cache dentries and inodes.


If you only want to test fuse's caching, I would try mounting the
volume on a separate machine (not on the brick node itself),
disable all gluster performance xlators, do a find.|xargs stat on
the mount 2 times in succession and see what free(1) reports the
1st and 2nd time. You could do this experiment with various
attr/entry timeout values. Make sure your volume has a lot of
small files.
-Ravi



在 2016-09-01 16:37:00，"Ravishankar N" 
写道：

On 09/01/2016 01:04 PM, Keiviw wrote:

Hi,
I have found that GlusterFS client(mounted by FUSE)
didn't cache metadata like dentries and inodes. I have
installed GlusterFS 3.6.0 in nodeA and nodeB, and the brick1
and brick2 was in nodeA, then in nodeB, I mounted the volume
to /mnt/glusterfs by FUSE. From my test, I excuted 'ls
/mnt/glusterfs' in nodeB, and found that the memory didn't
use at all. Here are my questions:
1. In fuse kernel, the author set some attributes to
control the time-out about dentry and inode, in other words,
the fuse kernel supports metadata cache, but in my test,
dentries and inodes were not cached. WHY?
2. Were there some options in GlusterFS mounted to local
to enable the metadata cache in fuse kernel?



You can tweak the attribute-timeout and entry-timeout seconds
while mounting the volume. Default is 1 second for both. 
`man mount.glusterfs` lists various mount options.

-Ravi




___
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] Checklist for gluster-swift for upstream release

2016-09-05 Thread Prashanth Pai 


- Original Message -
> From: "Pranith Kumar Karampuri" 
> To: tdasi...@redhat.com, "Prashanth Pai" 
> Cc: "Gluster Devel" 
> Sent: Saturday, 3 September, 2016 12:58:41 AM
> Subject: Checklist for gluster-swift for upstream release
> 
> hi,
> Did you get a chance to decide on the gluster-swift integration
> tests that need to be run before doing an upstream gluster release? Could
> you let me know who will be providing with the list?

The tests (unit test and functional test) can be run before doing
upstream release. These tests reside in gluster-swift repo.

I can run those tests (manually as of now) whenever required.

> 
> I can update it at https://public.pad.fsfe.org/p/
> gluster-component-release-checklist
> 
> 
> --
> Pranith
> 
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel

Re: [Gluster-devel] Spurious termination of fuse invalidation notifier thread

2016-09-05 Thread Xavier Hernandez 

Hi Raghavendra,

On 06/09/16 06:11, Raghavendra Gowdappa wrote:



- Original Message -

From: "Xavier Hernandez" 
To: "Raghavendra Gowdappa" , "Kaleb Keithley" , 
"Pranith Kumar Karampuri"

Cc: "Csaba Henk" , "Gluster Devel" 
Sent: Monday, September 5, 2016 12:46:43 PM
Subject: Re: Spurious termination of fuse invalidation notifier thread

Hi Raghavendra,

On 03/09/16 05:42, Raghavendra Gowdappa wrote:

Hi Xavi/Kaleb/Pranith,

During few of our older conversations (like [1], but not only one), some of
you had reported that the thread which writes invalidation notifications
(of inodes, entries) to /dev/fuse terminates spuriously. Csaba tried to
reproduce the issue, but without success. It would be helpful if you
provide any information on reproducer and/or possible reasons for the
behavior.


I didn't found what really caused the problem. I only saw the
termination message on a production server after some days working but
hadn't had the opportunity to debug it.

Looking at the code, the only conclusion I got is that the result from
the write to /dev/fuse was unexpected. The patch solves this and I
haven't seen the problem again.

The old code only manages ENOENT error. It exits the thread for any
other error. I guess that in some situations a write to /dev/fuse can
return other "non fatal" errors.


Thanks Xavi. Now I remember the changes. Since you have not seen spurious 
termination after the changes, I assume the issue is fixed.


Yes, I haven't seen the issue again since the patch was applied.





As a guess, I think it may be a failure in an entry invalidation.
Looking at the code of fuse, it may return ENOTDIR if parent of the
entry is not a directory and some race happens doing rm/create while
sending invalidations in the background. Another possibility is
ENOTEMPTY if the entry references a non empty directory (again probably
caused by races between user mode operations and background
invalidations). Anyway this is only a guess, I have no more information.

Xavi



[1]
http://review.gluster.org/#/c/13274/1/xlators/mount/fuse/src/fuse-bridge.c

regards,
Raghavendra




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

Re: [Gluster-devel] How to enable FUSE kernel cache about dentry and inode?

2016-09-05 Thread Keiviw 
Could you please tell me your glusterfs version and the mount command that you 
have used?? My GlusterFS version is 3.3.0, different versions may be exits 
different results.






At 2016-09-06 12:35:19, "Ravishankar N"  wrote:

That is strange. I tried the experiment on a volume with a million files. The 
client node's memory usage did grow, as I observed from the output of free(1)  
http://paste.fedoraproject.org/422551/ when I did a `ls`.
-Ravi
 
On 09/02/2016 07:31 AM, Keiviw wrote:

Exactly, I mounted the volume in a no-brick node(nodeB), and nodeA was the 
server. I have set different timeout, but when I excute "ls 
/mnt/glusterfs(about 3 million small files, in other words, about 3 million 
dentries)", the result was the same, memory usage in nodeB didn't change at all 
while nodeA's memory usage was changed about 4GB!


发自 网易邮箱大师
On 09/02/2016 09:45, Ravishankar N wrote:
On 09/02/2016 05:42 AM, Keiviw wrote:

Even if I set the attribute-timeout and entry-timeout to 3600s(1h), in the 
nodeB, it didn't cache any metadata because the memory usage didn't change. So 
I was confused that why did the client not cache dentries and inodes.


If you only want to test fuse's caching, I would try mounting the volume on a 
separate machine (not on the brick node itself), disable all gluster 
performance xlators, do a find.|xargs stat on the mount 2 times in succession 
and see what free(1) reports the 1st and 2nd time. You could do this experiment 
with various attr/entry timeout values. Make sure your volume has a lot of 
small files.
-Ravi



在 2016-09-01 16:37:00，"Ravishankar N"  写道：

On 09/01/2016 01:04 PM, Keiviw wrote:

Hi,
I have found that GlusterFS client(mounted by FUSE) didn't cache metadata 
like dentries and inodes. I have installed GlusterFS 3.6.0 in nodeA and nodeB, 
and the brick1 and brick2 was in nodeA, then in nodeB, I mounted the volume to 
/mnt/glusterfs by FUSE. From my test, I excuted 'ls /mnt/glusterfs' in nodeB, 
and found that the memory didn't use at all. Here are my questions:
1. In fuse kernel, the author set some attributes to control the time-out 
about dentry and inode, in other words, the fuse kernel supports metadata 
cache, but in my test, dentries and inodes were not cached. WHY?
2. Were there some options in GlusterFS mounted to local to enable the 
metadata cache in fuse kernel? 


You can tweak the attribute-timeout and entry-timeout seconds while mounting 
the volume. Default is 1 second for both.  `man mount.glusterfs` lists various 
mount options.
-Ravi


 




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








 









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