From: "A. Wilcox" <awilfox@adelielinux.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: linux-ext4@vger.kernel.org
Subject: Re: t_ext_jnl_rm test takes 96 seconds to finish
Date: Wed, 2 Oct 2019 15:59:48 -0500 [thread overview]
Message-ID: <433847ea-0ffd-bb35-6b8f-c10fb96bda34@adelielinux.org> (raw)
In-Reply-To: <20191002195955.GC777@mit.edu>
[-- Attachment #1.1: Type: text/plain, Size: 2255 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2019-10-02 20:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-02 18:16 t_ext_jnl_rm test takes 96 seconds to finish A. Wilcox
2019-10-02 19:59 ` Theodore Y. Ts'o
2019-10-02 20:59 ` A. Wilcox [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=433847ea-0ffd-bb35-6b8f-c10fb96bda34@adelielinux.org \
--to=awilfox@adelielinux.org \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox