Re: It looks wrong for the timeout when lvm test running

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Zdenek,

Thank you for your feedback.
When I switched to ramdisk backend devices, the time consuming is about 9s.

I raised this topic for there may have a bug in timeout related codes,
not for why the snapshot-merge.sh costs too much time.

The code in below overwrite silent_start when select() successfully return.
```
           if ( select( nfds, &set, NULL, NULL, &wait ) > 0 ) {
               silent_start = end; /* something happened */ <====== this line!
               io.sync( false );
           }
```

Thanks.

On 12/9/19 7:36 PM, Zdenek Kabelac wrote:
> Dne 09. 12. 19 v 11:58 Heming Zhao napsal(a):
>> Hello Zdenek,
>>
>> Please check the compressed file in attachment.
>>
>>>
>> On 12/9/19 5:40 PM, Zdenek Kabelac wrote:
>>> Dne 09. 12. 19 v 10:20 Heming Zhao napsal(a):
>>>> Hello List,
>>>>
>>>> The lvm test default timeout (--timeout) default value is 180.
>>>> But I met below condition when running testcase (in virtual machine):
>>>> ```
>>>> make check_local T=shell/snapshot-merge.sh
>>>>       ... ...
>>>> ###       passed: [ndev-vanilla] shell/snapshot-merge.sh 665
>>>>       ... ...
>>>> ```
> 
> 
> Hi
> 
> 
> So your test seems to be very slow in 'mkfs.ext4':
> 
> [ 0:03] Creating journal (4096 blocks): done
> [ 1:30] Writing superblocks and filesystem accounting information: done
> ....
> [ 1:34] Creating journal (4096 blocks): done
> [ 3:03] Writing superblocks and filesystem accounting information: done
> ....
> [ 3:07] Creating journal (4096 blocks): done
> [ 4:37] Writing superblocks and filesystem accounting information: done
> ....
> [ 4:40] Creating journal (4096 blocks): done
> [ 6:08] Writing superblocks and filesystem accounting information: done
> ....
> 
> 
> This looks certainly seriously like a very slow (possibly doing TRIM) ??
> Any idea why ?
> 
> The test seems to be using loop device created in backend file in your /tmp
> (i.e.: losetup /dev/loop0 /tmp/LVMTEST11574.cJtNfnlPrj/test.img)
> 
> So any idea why your virtual machine is that slow with handling this case ?
> 
> One idea - aren't you using a storage with very slow discard processing
> (i.e. ATM VDO) ?
> 
> You can setup different backend device or different location of test dir
> (see 'make help' in test subdir)
> 
> Regards
> 
> Zdenek
> 


_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/





[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux