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 On Fri, Jul 22, 2016 at 7:44 PM, Nithya Balachandran <nbala...@redhat.com> wrote: > > > On Fri, Jul 22, 2016 at 7:42 PM, Pranith Kumar Karampuri < > pkara...@redhat.com> wrote: > >> >> >> On Fri, Jul 22, 2016 at 7:39 PM, Nithya Balachandran <nbala...@redhat.com >> > wrote: >> >>> >>> >>> On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy <jda...@redhat.com> 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@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 >>> >> >> >> >> -- >> Pranith >> > > -- Pranith
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel