On Sat, Jul 23, 2016 at 9:45 AM, Nithya Balachandran <nbala...@redhat.com> wrote:
> > > On Fri, Jul 22, 2016 at 9:07 PM, Pranith Kumar Karampuri < > pkara...@redhat.com> wrote: > >> >> >> On Fri, Jul 22, 2016 at 8:12 PM, Pranith Kumar Karampuri < >> pkara...@redhat.com> 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 < >>> 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 >>> >> >> >> >> -- >> Pranith >> >
_______________________________________________ Gluster-devel mailing list Gluster-devel@gluster.org http://www.gluster.org/mailman/listinfo/gluster-devel