[Gluster-devel] Glusterfs v4.1.1 issue encountered while executing test case ./tests/basic/namespace.t

Vijay Bellur vbellur at redhat.com
Fri Aug 17 22:33:33 UTC 2018


Hi Abhay,

Would it be possible for you to change the namsepace.t and trash.t (as
discussed in IRC) tests to work with both endian architectures?

Both failures seem to be linked to the issue that SuperFastHash() provides
different values on little & big endian architectures. You could do
something like `lspcu | grep "Little Endian" to determine the endianess and
this value can be used to have the right behavior in tests.

Please feel free to let me know if you need more assistance in fixing both
namespace.t and trash.t tests.

Regards,
Vijay


On Mon, Aug 13, 2018 at 12:26 PM Abhay Singh <abhays at us.ibm.com> wrote:

> Hi,
> I am working on Glusterfs v4.1.1 for Ubuntu 16.04 on big endian
> architecture. After successful build and running the test cases, I
> encountered a test case failure. The test case is:-
> ·        ./tests/basic/namespace.t
>
> In the test case *./tests/basic/namespace.t*, a NAMESPACE_HASH is
> generated after  calling  a SuperFastHash() function on the corresponding
> folder names. This hash differs on big endian  and little endian
> architectures. Therefore, I have changed the code accordingly. Although
> there is another subtest in this test which fails with the following error:-
> TEST 30 (line 119): Y check_samples CREATE 1268089390 /namespace3/file
> patchy0
> getfattr: /d/backends/patchy0/namespace3/file: No such file or directory
>
> As seen above, the error is occurring because the folder
> /d/backends/patchy0/namespace3/ doesn’t contain “file”. However, I resolved
> this subtest by changing the folder to /d/backends/patchy6/namespace3/
> where “file” is actually present.
> But same is not the case for little endian architectures where the test
> case passes without any changes.
> The type of filesystem /d/backends is “ext4” and there is enough space
> allocated to the directory.
> Therefore, could you please provide me with some more insight as to why is
> this happening?
>
>
> *Thanks and Regards,*
> *Abhay Singh*
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> https://lists.gluster.org/mailman/listinfo/gluster-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180817/7dc750a3/attachment.html>


More information about the Gluster-devel mailing list