Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

Hi Avra, Thanks for the reply, But the problem I see here is the previous patch set sent would'nt compile individually. So, I merged the changes into a single patch , which i'd posted today. Is it ok to drop all the previous posted patches and consider from the new one? Please suggest.

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

Hi Sriram, I have already provided comments on the new patch. It seems this new patch while addressing merge cloflicts, has undone some previous patches. I suggest you send this patch on top of the previous patchset(http://review.gluster.org/#/c/15554/1) instead of creating a new one. This

Re: [Gluster-devel] Question on merging zfs snapshot support into the mainline glusterfs

Hi Avra, I've update the patch according to the comments below. And created a single patch which does the initial modularization. Fixed the tab- >space issue as well. I've raised a new review request for the same bug ID here: http://review.gluster.org/#/c/16138/ Added, Rajesh and You as the

[Gluster-devel] [Focus Area] Gluster Experience for Developers and Integrations (GEDI)

One of the goals for Gluster is to have integrations with/for other projects. The Gluster project is adopting a structure based upon "Focus Areas". There are listed in the GitHub project at [0]. The name for the "focus area" started as "Developer Experience". But this term is used a lot recently,

Re: [Gluster-devel] semantics about OPEN in NFS

> > > I do not expect that any of the xlators will call OPEN. From my > understanding of what you wrote, I assume that debug/io-stats is not > very functional when using Gluster/NFS. > > You also seem to have conformed in your original email that the > statistics are not complete. Reporting that

Re: [Gluster-devel] semantics about OPEN in NFS

On Wed, Dec 14, 2016 at 06:54:27PM +0800, jin deng wrote: > > > > > > > Te NFSv3 protocol does not have a OPEN procedure. When an NFSv3 client > > wants to read/write a file, the operations are like: > > > > 1. LOOKUP of the filename, returns a filehandle on success > > 2. WRITE data with

Re: [Gluster-devel] semantics about OPEN in NFS

> > > Te NFSv3 protocol does not have a OPEN procedure. When an NFSv3 client > wants to read/write a file, the operations are like: > > 1. LOOKUP of the filename, returns a filehandle on success > 2. WRITE data with offset in the filehandle > > A LOOKUP is like stat(), and the filehandle is a

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

On Wed, Dec 14, 2016 at 10:30:46AM +0100, Niels de Vos wrote: > On Wed, Dec 14, 2016 at 04:10:38AM -0500, Poornima Gurusiddaiah wrote: > > 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.

Re: [Gluster-devel] semantics about OPEN in NFS

On Wed, Dec 14, 2016 at 10:28:01AM +0800, jin deng wrote: > hello, > After reading the "nfs" xlator i'm doing some statistics work with > "debug/io-stats" and find that only the open/create/mkdir will do the " > *ios_inode_ctx_set*" means other operations such readv(not created during > the

Re: [Gluster-devel] 1402538 : Assertion failure during rebalance of symbolic links

On 12/14/2016 10:28 AM, Pranith Kumar Karampuri wrote: On Wed, Dec 14, 2016 at 2:54 PM, Xavier Hernandez > wrote: On 12/14/2016 10:17 AM, Pranith Kumar Karampuri wrote: On Wed, Dec 14, 2016 at 1:48 PM, Xavier Hernandez

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

On Wed, Dec 14, 2016 at 04:10:38AM -0500, Poornima Gurusiddaiah wrote: > 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.

Re: [Gluster-devel] 1402538 : Assertion failure during rebalance of symbolic links

On 12/14/2016 10:17 AM, Pranith Kumar Karampuri wrote: On Wed, Dec 14, 2016 at 1:48 PM, Xavier Hernandez > wrote: There's another issue with the patch that Ashish sent. The original problem is that a setattr on a symbolic link gets

Re: [Gluster-devel] 1402538 : Assertion failure during rebalance of symbolic links

On Wed, Dec 14, 2016 at 1:48 PM, Xavier Hernandez wrote: > There's another issue with the patch that Ashish sent. > > The original problem is that a setattr on a symbolic link gets transformed > to a regular file while the fop is being executed. Even if we apply the >

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

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

Re: [Gluster-devel] 1402538 : Assertion failure during rebalance of symbolic links

There's another issue with the patch that Ashish sent. The original problem is that a setattr on a symbolic link gets transformed to a regular file while the fop is being executed. Even if we apply the Ashish' patch to avoid the assert, the setattr fop will still succeed and incorrectly

Re: [Gluster-devel] Release 3.10 feature proposal : Gluster Block Storage CLI Integration

On Wed, Dec 14, 2016 at 12:40:53PM +0530, Prasanna Kumar Kalever wrote: > On 16-12-14 07:43:05, Niels de Vos wrote: > > On Fri, Dec 09, 2016 at 11:28:52AM +0530, Prasanna Kalever wrote: > > > Hi all, > > > > > > As we know gluster block storage creation and maintanace is not simple > > > today,

Re: [Gluster-devel] 1402538 : Assertion failure during rebalance of symbolic links

On 12/14/2016 06:10 AM, Raghavendra Gowdappa wrote: - Original Message - From: "Pranith Kumar Karampuri" To: "Ashish Pandey" Cc: "Gluster Devel" , "Shyam Ranganathan" , "Nithya Balachandran"