[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <433847ea-0ffd-bb35-6b8f-c10fb96bda34@adelielinux.org>
Date: Wed, 2 Oct 2019 15:59:48 -0500
From: "A. Wilcox" <awilfox@...lielinux.org>
To: "Theodore Y. Ts'o" <tytso@....edu>
Cc: linux-ext4@...r.kernel.org
Subject: Re: t_ext_jnl_rm test takes 96 seconds to finish
On 02/10/2019 14:59, Theodore Y. Ts'o wrote:
> On Wed, Oct 02, 2019 at 01:16:51PM -0500, A. Wilcox wrote:
>> While building e2fsprogs 1.45.4, I noticed the following output during
>> testing:
>>
>> t_ext_jnl_rm: remove missing external journal device: ok
>> t_ext_jnl_rm: *** took 96 seconds to finish ***
>> t_ext_jnl_rm: consider adding t_ext_jnl_rm/is_slow_test
>>
>> I didn't see any mention of this in the list archives, and I'm not
>> entirely sure if it should really be marked as a slow test.
>
> The first time I ran this test, it took 20 seconds. (And that was
> only because I had a WDC external SSD attached to my laptop and it
> took time to spin it up; more on that below.) The next time, it was
> nearly instaneous:
>
> % time ./test_script t_ext_jnl_rm
> t_ext_jnl_rm: remove missing external journal device: ok
> 356 tests succeeded 0 tests failed
>
> real 0m0.242s
> user 0m0.053s
> sys 0m0.114s
>
> If you look at the test script, you'll see that we are creating a file
> system, setting up an external journal which doesn't exist:
>
>
> ... and then we ask tune2fs to remove the journal:
>
>
> So the time that it takes is based on how long it takes to search all
> of the disks attached to the system looking for an external journal
> with the uuid 1db3f677-6832-4adb-bafc-8e4059c30a33.
>
> On most systems, this is fast. If you happen to have a slow device
> attached to your system, then this can take a while --- but there's
> really not much we can do about this. I suppose we could try to add a
> test mock which disables the external journal search, if there isn't
> any way you can speed things up on your end now that you know what's
> causing the delay?
>
> - Ted
Ah, okay. This machine happened to have backup devices still connected
which are external USB spinning rust drives. They could easily take 30+
seconds to spin up, each, and there were two. Additionally it has a
caching HDD internally that may have been spun down. That explains it.
Thank you for making sense of this, and doing so promptly. I really
appreciate it!
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Powered by blists - more mailing lists