Linux EXT4 FS development
 help / color / mirror / Atom feed
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 --]

      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