Re: 3.7 regressions on NetBSD

[Nithya Balachandran <nbalacha@xxxxxxxxxx>]

On Sat, Jul 23, 2016 at 9:45 AM, Nithya Balachandran <nbalacha@xxxxxxxxxx> wrote:

On Fri, Jul 22, 2016 at 9:07 PM, Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> wrote:

On Fri, Jul 22, 2016 at 8:12 PM, Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> wrote:

I am playing with the following diff, let me see.

diff --git a/tests/volume.rc b/tests/volume.rc
index 331a802..b288508 100644
--- a/tests/volume.rc
+++ b/tests/volume.rc
@@ -579,7 +579,9 @@ function num_graphs
 function get_aux()
 {
 ##Check if a auxiliary mount is there
-df -h 2>&1 | sed 's#/build/install##' | grep -e "[[:space:]]/run/gluster/${V0}$" -e "[[:space:]]/var/run/gluster/${V0}$" -
+local rundir=$(gluster --print-statedumpdir)
+local pid=$(cat ${rundir}/${V0}.pid)
+pidof glusterfs 2>&1 | grep -w $pid
 
 if [ $? -eq 0 ]
 then

Based on what I saw in code, this seems to get the job done. Comments welcome:
http://review.gluster.org/14988

Nice work Pranith :)

All, once this is backported to release-3.7, any patches on release-3.7 patches will need to be rebased so they will pass the NetBSD regression.

I am suddenly confused about this - will the patches need to be rebased or with the next run automatically include the changes once Pranith's fix is merged? 

On Fri, Jul 22, 2016 at 7:44 PM, Nithya Balachandran <nbalacha@xxxxxxxxxx> wrote:

On Fri, Jul 22, 2016 at 7:42 PM, Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> wrote:

On Fri, Jul 22, 2016 at 7:39 PM, Nithya Balachandran <nbalacha@xxxxxxxxxx> wrote:

On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote:

> I attempted to get us more space on NetBSD by creating a new partition called
> /data and putting /build as a symlink to /data/build. This has caused
> problems
> with tests/basic/quota.t. It's marked as bad for master, but not for
> release-3.7. This is possibly because we have a hard-coded grep for
> /build/install against df -h.

For the benefit of anyone else looking at this, the grep actually seems to be
in volume.rc and not in the test itself.

That's right -  it appears to have been done to exclude the install path components from the df output which is what is being done to find the aux mount. Is there a better way to figure out if the aux mount is running?

> Nithya has spent the last 2 days debugging
> without much success. What's a good way forward here? Mark the test as
> failing for 3.7?

Right. Something went wrong with the system and it refused to run the tests after a while. 

 

I don't think so.  There are 13 tests that use the affected function
(get_aux).  Do we want to disable 13 tests?  I think we actually need
to fix the function instead.  It seems to me that the check we're
making is very hacky in two ways:

   Checking for both /run and /var/run instead of using GLUSTERD_WORKDIR

   Excluding /build/install for no obvious reason at all

This looks like it was done to remove the /build/install components from the df -h outputs. Changing the path to /data/build/install broke this as it did not strip the "/data" from the paths.

It did work when I changed the sed to act on /data/build/install but hardcoded paths are not a good approach.

Give me some time, I can send out a patch to print out the default run directory if that helps?

something similar to 'gluster --print-logdir'. What shall we call this? 'gluster --print-rundir'? it will

 

This path might be available as an env variable - but is there a better way to figure out the aux mount without bothering with df -h?  

These auxiliary mounts should be in a much more specific place, and we
should check for that instead of looking for any that might exist.  Who
knows where that place is?  I've copied Raghavendra G as the quota
maintainer, since that seems like our best bet.

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

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

--

Pranith

--

Pranith

--

Pranith

 

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