Re: [Gluster-devel] All builds are failing with BUILD ERROR
On 06/02/2014 10:58 AM, Vijay Bellur wrote: Seems to have been resolved now. Do you folks happen to know how it was fixed? someone cleaned the loopback devices. I deleted 500 unix domain sockets in /d/install/var/run and requeued the regressions. I'm not sure which of those two things was the solution. -- Kaleb ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] doubts in posix_handle_path and posix_handle_pump
hi Avati,
Could you please explain why posix_handle_pump fixes ELOOP.
posix_handle_path seems to return gfid-path when the lstat on the base-gfid
path fails. I am not sure what the behaviour is supposed to be.
I added the snippet of code for reference below.
346 base_len = (priv->base_path_length + SLEN(GF_HIDDEN_PATH) + 45);
347 base_str = alloca (base_len + 1);
348 base_len = snprintf (base_str, base_len + 1, "%s/%s/%02x/%02x/%s",
349 priv->base_path, GF_HIDDEN_PATH, gfid[0],
gfid[1],
350 uuid_str);
351
352 pfx_len = priv->base_path_length + 1 + SLEN(GF_HIDDEN_PATH) + 1;
353
354 if (basename) {
355 len = snprintf (buf, maxlen, "%s/%s", base_str, basename);
356 } else {
357 len = snprintf (buf, maxlen, "%s", base_str);
358 }
359
360 ret = lstat (base_str, &stat);
361
362 if (!(ret == 0 && S_ISLNK(stat.st_mode) && stat.st_nlink == 1))
<<<-
363 goto out;
Pranith.
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] inode lru limit
On Fri, May 30, 2014 at 2:24 PM, Raghavendra Bhat wrote: > > Hi, > > Currently the lru-limit of the inode table in brick processes is 16384. > There is a option to configure it to some other value. The protocol/server > uses inode_lru_limit variable present in its private structure while > creating the inode table (whose default value is 16384). When the option is > reconfigured via volume set option the protocol/server's inode_lru_limit > variable present in its private structure is changed. But the actual size > of the inode table still remains same as old one. Only when the brick is > restarted the newly set value comes into picture. Is it ok? Should we > change the inode table's lru_limit variable also as part of reconfigure? If > so, then probably we might have to remove the extra inodes present in the > lru list by calling inode_table_prune. > Yes, I think we should change the inode table's lru limit too and call inode_table_prune. From what I know, I don't think this change would cause any problems. > > Please provide feedback > > > Regards, > Raghavendra Bhat > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > -- Raghavendra G ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] All builds are failing with BUILD ERROR
On 06/01/2014 04:13 PM, Justin Clift wrote: It _may_ be related to the new regression test cleanup function I'm working on: http://review.gluster.org/#/c/7937/ (possibly cleaned up / removed too much stuff) It also might not be, as it's only supposed to have run on the slaves. + Justin On 01/06/2014, at 9:18 AM, Pranith Kumar Karampuri wrote: I see that all builds that were submitted yesterday failed with BUILD FAILURE Here is the snippet of the log containing Failure: Please proceed with configuring, compiling, and installing. rm: cannot remove `/build/install/var/run/gluster/patchy': Device or resource busy + RET=1 + '[' 1 '!=' 0 ']' + VERDICT='BUILD FAILURE' Seems to have been resolved now. Do you folks happen to know how it was fixed? Thanks, Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] struct dirent in snapview-server.c
> > It is always possible to translate structures, the question is whether > it is useful of not. d_off is the offset of this struct dirent within > the buffer for the whole directory returned by getdents(2) system call. > > Since we glusterfs does not use getdents(2) but upper level > opendir(3)/readdir(3), which use getdents(2) themselves, it never has > the whole buffer, and therefore I am not sure it can make any use of > d_off. Understood that makes sense. -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] struct dirent in snapview-server.c
Harshavardhana wrote: > On the other hand NetBSD has 'sys/compat/linux/*' - can we not > leverage it? is it some dependency which is not warranted? It is always possible to translate structures, the question is whether it is useful of not. d_off is the offset of this struct dirent within the buffer for the whole directory returned by getdents(2) system call. Since we glusterfs does not use getdents(2) but upper level opendir(3)/readdir(3), which use getdents(2) themselves, it never has the whole buffer, and therefore I am not sure it can make any use of d_off. A look at the sources suggests it fills d_off in other places, but never use it. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] struct dirent in snapview-server.c
Emmanuel i sent a patch to disable building snapview on OSX, since it was of no use on 'darwin' . You could see if snapshots and snapview would work on NetBSD (LVM support), in such cases one doesn't have to disable it for NetBSD. d_off might be necessary internally, turning it off might not make snapshots properly work for BSD. Snapshot team can explain better. On the other hand NetBSD has 'sys/compat/linux/*' - can we not leverage it? is it some dependency which is not warranted? On Sun, Jun 1, 2014 at 10:31 AM, Emmanuel Dreyfus wrote: > Emmanuel Dreyfus wrote: > >> Linux and NetBSD struct dirent do not have the same layout, and in fact >> the whole buffer returned by readdir() has a different layout and is not >> straightforward to convert. > > After reading further, there are struct dirent used in many other places > without a hitch. The build breaks here because the d_off field is > copied, and this field does not exist in NetBSD struct dirent. > > Is d_off used anywhere else? If not then I can fix the build with this: > > --- a/xlators/features/snapview-server/src/snapview-server.c > +++ b/xlators/features/snapview-server/src/snapview-server.c > @@ -1600,7 +1600,9 @@ svs_glfs_readdir (xlator_t *this, glfs_fd_t *glfd, > strerror (errno)); > break; > } > +#ifdef linux > entry->d_off = de.d_off; > +#endif > entry->d_ino = de.d_ino; > entry->d_type = de.d_type; > iatt_from_stat (buf, &statbuf); > > -- > Emmanuel Dreyfus > http://hcpnet.free.fr/pubz > m...@netbsd.org > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] struct dirent in snapview-server.c
Emmanuel Dreyfus wrote: > Linux and NetBSD struct dirent do not have the same layout, and in fact > the whole buffer returned by readdir() has a different layout and is not > straightforward to convert. After reading further, there are struct dirent used in many other places without a hitch. The build breaks here because the d_off field is copied, and this field does not exist in NetBSD struct dirent. Is d_off used anywhere else? If not then I can fix the build with this: --- a/xlators/features/snapview-server/src/snapview-server.c +++ b/xlators/features/snapview-server/src/snapview-server.c @@ -1600,7 +1600,9 @@ svs_glfs_readdir (xlator_t *this, glfs_fd_t *glfd, strerror (errno)); break; } +#ifdef linux entry->d_off = de.d_off; +#endif entry->d_ino = de.d_ino; entry->d_type = de.d_type; iatt_from_stat (buf, &statbuf); -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] struct dirent in snapview-server.c
Hi NetBSD build chokes in master because of struct dirent usage in snapview-server.c:svs_glfs_readdir() Linux and NetBSD struct dirent do not have the same layout, and in fact the whole buffer returned by readdir() has a different layout and is not straightforward to convert. Where does the struct dirent comes from? Is it from a readdir() system call? In that case I need to translate the structure, but it may be wiser to do it earlier, i.e. just after readdir() call. Anyone can tell me how this is supposed to work? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz m...@netbsd.org ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] All builds are failing with BUILD ERROR
It _may_ be related to the new regression test cleanup function I'm working on: http://review.gluster.org/#/c/7937/ (possibly cleaned up / removed too much stuff) It also might not be, as it's only supposed to have run on the slaves. + Justin On 01/06/2014, at 9:18 AM, Pranith Kumar Karampuri wrote: > I see that all builds that were submitted yesterday failed with BUILD FAILURE > Here is the snippet of the log containing Failure: > Please proceed with configuring, compiling, and installing. > rm: cannot remove `/build/install/var/run/gluster/patchy': Device or resource > busy > + RET=1 > + '[' 1 '!=' 0 ']' > + VERDICT='BUILD FAILURE' > > Pranith > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel -- Open Source and Standards @ Red Hat twitter.com/realjustinclift ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
[Gluster-devel] All builds are failing with BUILD ERROR
I see that all builds that were submitted yesterday failed with BUILD FAILURE Here is the snippet of the log containing Failure: Please proceed with configuring, compiling, and installing. rm: cannot remove `/build/install/var/run/gluster/patchy': Device or resource busy + RET=1 + '[' 1 '!=' 0 ']' + VERDICT='BUILD FAILURE' Pranith ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
