From mboxrd@z Thu Jan 1 00:00:00 1970 References: <9fdc2f47-a4db-f472-e1eb-424f6a6b28d9@suse.com> <47ab183b-3a61-24f1-77e8-1d3aa2cf3c29@redhat.com> From: Zdenek Kabelac Message-ID: <5e05b9df-c18b-64f9-6e4f-19f33ad01d1a@redhat.com> Date: Tue, 10 Dec 2019 10:03:51 +0100 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [linux-lvm] It looks wrong for the timeout when lvm test running Reply-To: LVM general discussion and development List-Id: LVM general discussion and development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Heming Zhao , LVM general discussion and development Dne 10. 12. 19 v 4:23 Heming Zhao napsal(a): > 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 ); > } > ``` Hi This is intentional - the idea of this 'timeout' is - that during the timeout period there is no progress on output (i.e. for 180s there was nothing printed - which likely means something got locked - there is also secondary limitation on number of output lines - so if something is doing endless printing loop, it's also catched before it fill all disk spaces on testing machine... - hopefully this explains 'something happened' comment. In general we don't have strict 'limit' for test length in time - although if test takes 10 minutes - it's likely not what was intended - but we don't have that rule on individual test time as speed often largely depends on machine performance. Zdenek