[Gluster-devel] 3.7 regressions on NetBSD
Pranith Kumar Karampuri
pkarampu at redhat.com
Fri Jul 22 14:42:49 UTC 2016
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 <nbalacha at redhat.com>
wrote:
>
>
> On Fri, Jul 22, 2016 at 7:42 PM, Pranith Kumar Karampuri <
> pkarampu at redhat.com> wrote:
>
>>
>>
>> On Fri, Jul 22, 2016 at 7:39 PM, Nithya Balachandran <nbalacha at redhat.com
>> > wrote:
>>
>>>
>>>
>>> On Fri, Jul 22, 2016 at 7:31 PM, Jeff Darcy <jdarcy at 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 at gluster.org
>>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>>
>>>
>>>
>>> _______________________________________________
>>> Gluster-devel mailing list
>>> Gluster-devel at gluster.org
>>> http://www.gluster.org/mailman/listinfo/gluster-devel
>>>
>>
>>
>>
>> --
>> Pranith
>>
>
>
--
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160722/6781ad59/attachment.html>
More information about the Gluster-devel
mailing list