[Gluster-devel] 3.7 regressions on NetBSD

Nithya Balachandran nbalacha at redhat.com
Fri Jul 22 14:09:57 UTC 2016


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.

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160722/f71e433d/attachment.html>


More information about the Gluster-devel mailing list