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 > Wait, it seems like 'gluster --print-statedumpdir' already prints '/var/run/gluster', is this the directory we want? > > >> >>> 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