[Gluster-devel] Need help from FreeBSD developers
hi, Based on the debugging done by Niels on the bug https://bugzilla.redhat.com/show_bug.cgi?id=1181500#c5, we need a confirmation about what listxattr returns on FreeBSD. Could someone please help? -- Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Please do not edit Jenkins Jobs
Hello folks, I missed out mentioning this in my previous emails. Please do not any jobs on build.gluster.org. I'm in the process of converting them to Jenkins Job Builder. This process involves writing yaml and comparing the xml against our existing xml (I'll update the repo today with the latest version). It is essential that nothing changes to the old jobs as I do the migration. If we want to edit jobs in the future (and for the new jobs), they'll be done by editing the yaml code first. If you need to make urgent changes to something, please talk to me first before doing anything. -- nigelb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Need help from FreeBSD developers
On Fri, Jun 24, 2016 at 1:00 PM, Pranith Kumar Karampuri wrote: > hi, > Based on the debugging done by Niels on the bug > https://bugzilla.redhat.com/show_bug.cgi?id=1181500#c5, we need a > confirmation about what listxattr returns on FreeBSD. Could someone please > help? sys_llistxattr() is a wrapper around extattr_list_link() on BSDs, as defined in libglusterfs/src/syscall.c sys_llistxattr(path, list, size) -> extattr_list_link(path, EXTATTR_NAMESPACE_USER, list, size) The man page for extattr_list_link() is available at [1]. >From the man page, ''' extattr_list_file() returns a list of attributes present in the requested namespace. Each list entry consists of a single byte containing the length of the attribute name, followed by the attribute name. The attribute name is not terminated by ASCII 0 (nul). The extattr_get_file(), and extattr_list_file() calls consume the data and nbytes arguments in the style of read(2); ''' (The *link() syscalls behave the same as the *file() syscalls, expect they don't follow symlinks) ~kaushal [1] https://www.freebsd.org/cgi/man.cgi?query=extattr_list_link&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE+and+Ports&arch=default&format=html > > -- > Pranith > > ___ > 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] Need help from FreeBSD developers
On Fri, Jun 24, 2016 at 1:39 PM, Kaushal M wrote: > On Fri, Jun 24, 2016 at 1:00 PM, Pranith Kumar Karampuri > wrote: >> hi, >> Based on the debugging done by Niels on the bug >> https://bugzilla.redhat.com/show_bug.cgi?id=1181500#c5, we need a >> confirmation about what listxattr returns on FreeBSD. Could someone please >> help? > > sys_llistxattr() is a wrapper around extattr_list_link() on BSDs, as > defined in libglusterfs/src/syscall.c > > sys_llistxattr(path, list, size) -> extattr_list_link(path, > EXTATTR_NAMESPACE_USER, list, size) > > > The man page for extattr_list_link() is available at [1]. > > From the man page, > ''' > extattr_list_file() returns a list of attributes present in the requested > namespace. Each list entry consists of a single byte containing the > length of the attribute name, followed by the attribute name. The > attribute name is not terminated by ASCII 0 (nul). The > extattr_get_file(), and extattr_list_file() calls consume the data and > nbytes arguments in the style of read(2); > ''' > (The *link() syscalls behave the same as the *file() syscalls, expect > they don't follow symlinks) > The linux man entry for llistxattr is as follows, ''' listxattr() retrieves the list of extended attribute names associated with the given path in the filesystem. The retrieved list is placed in list, a caller-allocated buffer whose size (in bytes) is specified in the argu‐ ment size. The list is the set of (null-terminated) names, one after the other. Names of extended attributes to which the calling process does not have access may be omitted from the list. The length of the attribute name list is returned. llistxattr() is identical to listxattr(), except in the case of a symbolic link, where the list of names of extended attributes associated with the link itself is retrieved, not the file that it refers to. ''' There is a difference in the format used to return the names in the list. The procedure to iterate the list needs to be changed for FreeBSD, or the list needs to be normalized before sys_llistxattr() returns. > ~kaushal > > [1] > https://www.freebsd.org/cgi/man.cgi?query=extattr_list_link&apropos=0&sektion=0&manpath=FreeBSD+10.3-RELEASE+and+Ports&arch=default&format=html > >> >> -- >> Pranith >> >> ___ >> 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] nightly libgfapi-python tests are failing
Hi Prasanth, I just noticed that the nightly libgfapi-python tests in the CentOS CI are failing since a few days. I checked a few failures, and all look the same to me: FAIL: test_copyfileobj (test.functional.libgfapi-python-tests.FileOpsTest) -- Traceback (most recent call last): File "/root/libgfapi-python/test/functional/libgfapi-python-tests.py", line 665, in test_copyfileobj self.assertNotEqual(src_stat.st_atime, dest_stat.st_atime) AssertionError: 1466131919L == 1466131919L The first test run that failed is: https://ci.centos.org/view/Gluster/job/gluster_libgfapi-python/126/console I do not know if this is a new test, or if something in Gluster changed that now causes this failure. A new feature has been added to the CentOS CI. You can now add badges with the status of builds to documentation. Maybe you want to include that in the libgfapi-python wiki/readme? https://ci.centos.org/view/Gluster/job/gluster_libgfapi-python/badge/ Cheers, 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] nightly libgfapi-python tests are failing
- Original Message - > From: "Niels de Vos" > To: "Prashanth Pai" > Cc: gluster-devel@gluster.org > Sent: Friday, June 24, 2016 3:01:56 PM > Subject: nightly libgfapi-python tests are failing > > Hi Prasanth, > > I just noticed that the nightly libgfapi-python tests in the CentOS CI > are failing since a few days. I checked a few failures, and all look the > same to me: > > FAIL: test_copyfileobj > (test.functional.libgfapi-python-tests.FileOpsTest) > -- > Traceback (most recent call last): > File "/root/libgfapi-python/test/functional/libgfapi-python-tests.py", > line 665, in test_copyfileobj > self.assertNotEqual(src_stat.st_atime, dest_stat.st_atime) > AssertionError: 1466131919L == 1466131919L > > The first test run that failed is: > https://ci.centos.org/view/Gluster/job/gluster_libgfapi-python/126/console I'll take a look at it. It's a new test that was added. > > I do not know if this is a new test, or if something in Gluster changed > that now causes this failure. > > A new feature has been added to the CentOS CI. You can now add badges > with the status of builds to documentation. Maybe you want to include > that in the libgfapi-python wiki/readme? > https://ci.centos.org/view/Gluster/job/gluster_libgfapi-python/badge/ Cool, thanks for sharing. Will do. > > Cheers, > Niels > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] WORM/Retention Feature - 24/06/2016
Hi all, This week's status: -Updated the blog -Working on implementation of automatic state transition with WRITE FOP -While trying to set the utimes with write FOP, getting "posix_do_futimes not implemented" error -Looking into the posix code to implement the "posix_do_futimes" function Plan for next week: -Implementing the "posix_do_futimes" function and sending a patch for review Current work: Patch: http://review.gluster.org/#/c/13429/ http://review.gluster.org/#/c/14222/ http://review.gluster.org/#/c/14539/ http://review.gluster.org/#/c/14619/ Spec: https://github.com/gluster/glusterfs-specs/blob/master/under_review/worm-compliance.md Feature page: http://www.gluster.org/community/documentation/index.php/Features/gluster_compliance_archive Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1326308 https://bugzilla.redhat.com/show_bug.cgi?id=1333263 https://bugzilla.redhat.com/show_bug.cgi?id=1339524 https://bugzilla.redhat.com/show_bug.cgi?id=1341556 https://bugzilla.redhat.com/show_bug.cgi?id=1342259 https://bugzilla.redhat.com/show_bug.cgi?id=1345900 Blog: https://docs.google.com/document/d/1YSTDsbA93--AIU_myjqKkK2qTput0i0jOG2VMw_7mjc/edit?ts=5739915e# Thanks & Regards, Karthik ___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] Fuse client hangs on doing multithreading IO tests
Hi, We found a problem when doing traffic tests. We created a replicated volume with two storage nodes (CentOS 6.5). There was one FUSE client (CentOS 6.7) which did multi-threading reads and writes. Most of IOs are reads for big files. All machines used 10Gbe NICs. And the typical read throught was 4-6Gbps (0.5-1.5GB/s). After the test ran several minutes, the test program hung. The throughput suddenly dropped to zero. Then there was no traffic any more. If we ran df, df would hang, too. But we could still read or write the volume from other clients. We tried several GlusterFS version from 3.7.5 to 3.8.0. Each version had this problem. We also tried to restore default GlusterFS options, but the problem still existed. The GlusterFS version was 3.7.11 for the following stacks. This was the stack of dd when hanging: [a046d211] wait_answer_interruptible+0x81/0xc0 [fuse] [a046d42b] __fuse_request_send+0x1db/0x2b0 [fuse] [a046d512] fuse_request_send+0x12/0x20 [fuse] [a0477d4a] fuse_statfs+0xda/0x150 [fuse] [811c2b64] statfs_by_dentry+0x74/0xa0 [811c2c9b] vfs_statfs+0x1b/0xb0 [811c2e97] user_statfs+0x47/0xb0 [811c2f9a] sys_statfs+0x2a/0x50 [8100b072] system_call_fastpath+0x16/0x1b [] 0x This was the stack of gluster: [810b226a] futex_wait_queue_me+0xba/0xf0 [810b33a0] futex_wait+0x1c0/0x310 [810b4c91] do_futex+0x121/0xae0 [810b56cb] sys_futex+0x7b/0x170 [8100b072] system_call_fastpath+0x16/0x1b [] 0x This was the stack of the test program: [810a3f74] hrtimer_nanosleep+0xc4/0x180 [810a409e] sys_nanosleep+0x6e/0x80 [8100b072] system_call_fastpath+0x16/0x1b [] 0x Any clue? Thanks, Paul___ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] Fuse client hangs on doing multithreading IO tests
Hi, Any idea how big were the files that were being read? Can you please attach the logs from all the gluster server and client nodes? (the logs can be found in /var/log/glusterfs) Also please provide the /var/log/messages from all the server and client nodes. Regards, Raghavendra On Fri, Jun 24, 2016 at 10:32 AM, 冷波 wrote: > Hi, > > > We found a problem when doing traffic tests. We created a replicated > volume with two storage nodes (CentOS 6.5). There was one FUSE client > (CentOS 6.7) which did multi-threading reads and writes. Most of IOs are > reads for big files. All machines used 10Gbe NICs. And the typical read > throught was 4-6Gbps (0.5-1.5GB/s). > > > After the test ran several minutes, the test program hung. The throughput > suddenly dropped to zero. Then there was no traffic any more. If we ran df, > df would hang, too. But we could still read or write the volume from other > clients. > > > We tried several GlusterFS version from 3.7.5 to 3.8.0. Each version had > this problem. We also tried to restore default GlusterFS options, but the > problem still existed. > > > The GlusterFS version was 3.7.11 for the following stacks. > > > This was the stack of dd when hanging: > > [] wait_answer_interruptible+0x81/0xc0 [fuse] > > [] __fuse_request_send+0x1db/0x2b0 [fuse] > > [] fuse_request_send+0x12/0x20 [fuse] > > [] fuse_statfs+0xda/0x150 [fuse] > > [] statfs_by_dentry+0x74/0xa0 > > [] vfs_statfs+0x1b/0xb0 > > [] user_statfs+0x47/0xb0 > > [] sys_statfs+0x2a/0x50 > > [] system_call_fastpath+0x16/0x1b > > [] 0x > > > This was the stack of gluster: > > [] futex_wait_queue_me+0xba/0xf0 > > [] futex_wait+0x1c0/0x310 > > [] do_futex+0x121/0xae0 > > [] sys_futex+0x7b/0x170 > > [] system_call_fastpath+0x16/0x1b > > [] 0x > > > This was the stack of the test program: > > [] hrtimer_nanosleep+0xc4/0x180 > > [] sys_nanosleep+0x6e/0x80 > > [] system_call_fastpath+0x16/0x1b > > [] 0x > > > Any clue? > > Thanks, > Paul > > ___ > 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
