[Gluster-devel] tests/basic/op_errnos.t failure

Raghavendra Talur rtalur at redhat.com
Tue Jul 12 13:20:22 UTC 2016


Nigel/Misc,

Could you please look into this?
slave29 does not seem to have a xfs formatted backend for tests.

Thanks,
Raghavendra Talur

On Tue, Jul 12, 2016 at 6:41 PM, Avra Sengupta <asengupt at redhat.com> wrote:

> Atin,
>
> I am not sure about the docker containers, but both the failures you
> mentioned are in slave29, which as Talur explained is missing the
> appropriate backend filesystem. Owing to this, op-errno.t is just the tip
> of the iceberg, and every other test that uses lvm will fail in this
> particular slave will fail too.
>
> Talur,
> Thanks for looking into it. It is indeed strange this. I checked the dmesg
> and the /var/log/messages in this slave and I couldn't find any relevant
> log.
>
>
> On 07/12/2016 05:29 PM, Raghavendra Talur wrote:
>
> I checked the machine.
>
> Here is the df -hT output
> [jenkins at slave29 ~]$ cat /etc/fstab
> # Accessible filesystems, by reference, are maintained under '/dev/disk'
> # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
> #
> /dev/xvda1              /                       ext3
>  defaults,noatime,barrier=0 1 1
> tmpfs                   /dev/shm                tmpfs   defaults        0 0
> devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
> sysfs                   /sys                    sysfs   defaults        0 0
> proc                    /proc                   proc    defaults        0 0
> #/dev/xvdc1             none                    swap    sw              0 0
>
>
> We don't see a xfs device mounted at /d and / is of type ext3 which does
> not support fallocate. The uptime of the machine is 73 days though. I don't
> know how the /d xfs partition vanished.
>
> On Tue, Jul 12, 2016 at 4:54 PM, Atin Mukherjee < <amukherj at redhat.com>
> amukherj at redhat.com> wrote:
>
>>
>> https://build.gluster.org/job/rackspace-regression-2GB-triggered/22156/consoleFull
>> - another failure
>>
>> On Tue, Jul 12, 2016 at 4:42 PM, Atin Mukherjee < <amukherj at redhat.com>
>> amukherj at redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Jul 12, 2016 at 4:36 PM, Avra Sengupta < <asengupt at redhat.com>
>>> asengupt at redhat.com> wrote:
>>>
>>>> Hi Atin,
>>>>
>>>> Please check the testcase result in the console. It clearly states the
>>>> reason of the failure. A quick search of 30815, as shown in the testcase
>>>> shows that the error that is generated is a thinp issue, and we can see
>>>> fallocate failing and lvm not properly being setup in the environment.
>>>>
>>>
>>> While this is valid for my docker containers, I am just wondering why
>>> did this happen in jenkins slave?
>>>
>>>
>>>> Regards,
>>>> Avra
>>>>
>>>> P.S Here are the logs from the console stating so.
>>>>
>>>> *02:50:34* [09:50:34] Running tests in file ./tests/basic/op_errnos.t*02:50:41* fallocate: /d/backends/patchy_snap_vhd: fallocate failed: Operation not supported*02:50:41* losetup: /d/backends/patchy_snap_vhd: warning: file smaller than 512 bytes, the loop device maybe be useless or invisible for system tools.*02:50:41*   Device /d/backends/patchy_snap_loop not found (or ignored by filtering).*02:50:41*   Device /d/backends/patchy_snap_loop not found (or ignored by filtering).*02:50:41*   Unable to add physical volume '/d/backends/patchy_snap_loop' to volume group 'patchy_snap_vg_1'.*02:50:41*   Volume group "patchy_snap_vg_1" not found*02:50:41*   Cannot process volume group patchy_snap_vg_1*02:50:42*   Volume group "patchy_snap_vg_1" not found*02:50:42*   Cannot process volume group patchy_snap_vg_1*02:50:42* /dev/patchy_snap_vg_1/brick_lvm: No such file or directory*02:50:42* Usage: mkfs.xfs*02:50:42* /* blocksize */		[-b log=n|size=num]*02:50:42* /* data subvol */	[-d agcount=n,agsize=n,file,name=xxx,size=num,*02:50:42* 			    (sunit=value,swidth=value|su=num,sw=num),*02:50:42* 			    sectlog=n|sectsize=num*02:50:42* /* inode size */	[-i log=n|perblock=n|size=num,maxpct=n,attr=0|1|2,*02:50:42* 			    projid32bit=0|1]*02:50:42* /* log subvol */	[-l agnum=n,internal,size=num,logdev=xxx,version=n*02:50:42* 			    sunit=value|su=num,sectlog=n|sectsize=num,*02:50:42* 			    lazy-count=0|1]*02:50:42* /* label */		[-L label (maximum 12 characters)]*02:50:42* /* naming */		[-n log=n|size=num,version=2|ci]*02:50:42* /* prototype file */	[-p fname]*02:50:42* /* quiet */		[-q]*02:50:42* /* realtime subvol */	[-r extsize=num,size=num,rtdev=xxx]*02:50:42* /* sectorsize */	[-s log=n|size=num]*02:50:42* /* version */		[-V]*02:50:42* 			devicename*02:50:42* <devicename> is required unless -d name=xxx is given.*02:50:42* <num> is xxx (bytes), xxxs (sectors), xxxb (fs blocks), xxxk (xxx KiB),*02:50:42*       xxxm (xxx MiB), xxxg (xxx GiB), xxxt (xxx TiB) or xxxp (xxx PiB).*02:50:42* <value> is xxx (512 byte blocks).*02:50:42* mount: special device /dev/patchy_snap_vg_1/brick_lvm does not exist*02:50:53* ./tests/basic/op_errnos.t .. *02:50:53* 1..21*02:50:53* ok 1, LINENUM:12*02:50:53* ok 2, LINENUM:13*02:50:53* ok 3, LINENUM:14*02:50:53* ok 4, LINENUM:16*02:50:53* ok 5, LINENUM:18*02:50:53* ok 6, LINENUM:19*02:50:53* ok 7, LINENUM:20
>>>>
>>>>
>>>>
>>>>
>>>> On 07/12/2016 03:47 PM, Atin Mukherjee wrote:
>>>>
>>>> Hi Avra,
>>>>
>>>> The above fails locally as well along with few regression failures I
>>>> observed and one of them are at [1]
>>>>
>>>> not ok 12 Got "  30807" instead of "30809", LINENUM:26
>>>> FAILED COMMAND: 30809 get-op_errno-xml snapshot restore snap1
>>>>
>>>> not ok 17 Got "  30815" instead of "30812", LINENUM:31
>>>> FAILED COMMAND: 30812 get-op_errno-xml snapshot create snap1 patchy
>>>> no-timestamp
>>>>
>>>> [1]
>>>> <https://build.gluster.org/job/rackspace-regression-2GB-triggered/22154/console>
>>>> https://build.gluster.org/job/rackspace-regression-2GB-triggered/22154/console
>>>>
>>>> --Atin
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> --Atin
>>>
>>
>>
>>
>> --
>>
>> --Atin
>>
>> _______________________________________________
>> 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/20160712/445dddc2/attachment.html>


More information about the Gluster-devel mailing list