[linux-lvm] It looks wrong for the timeout when lvm test running
Heming Zhao
heming.zhao at suse.com
Tue Dec 10 03:23:52 UTC 2019
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
>
More information about the linux-lvm
mailing list