From: Donald Douwsma <ddouwsma@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>,
Eric Sandeen <sandeen@redhat.com>,
linux-xfs <linux-xfs@vger.kernel.org>
Cc: Leonardo Vaz <lvaz@redhat.com>,
"Darrick J. Wong" <darrick.wong@oracle.com>
Subject: Re: [PATCH V2] xfs_repair: fix progress reporting
Date: Wed, 20 May 2020 09:38:50 +1000 [thread overview]
Message-ID: <caab376d-22b1-39cd-0b71-8ca2d1e4dc3d@redhat.com> (raw)
In-Reply-To: <9b2caada-4057-b73f-ca54-87208084f266@sandeen.net>
On 19/05/2020 22:53, Eric Sandeen wrote:
> On 5/19/20 2:03 AM, Donald Douwsma wrote:
>>
>> On 19/05/2020 11:29, Eric Sandeen wrote:
>>> The Fixes: commit tried to avoid a segfault in case the progress timer
>>> went off before the first message type had been set up, but this
>>> had the net effect of short-circuiting the pthread start routine,
>>> and so the timer didn't get set up at all and we lost all fine-grained
>>> progress reporting.
>>>
>>> The initial problem occurred when log zeroing took more time than the
>>> timer interval.
>>>
>>> So, make a new log zeroing progress item and initialize it when we first
>>> set up the timer thread, to be sure that if the timer goes off while we
>>> are still zeroing the log, it will be initialized and correct.
>>>
>>> (We can't offer fine-grained status on log zeroing, so it'll go from
>>> zero to $LOGBLOCKS with nothing in between, but it's unlikely that log
>>> zeroing will take so long that this really matters.)
>>>
>>> Reported-by: Leonardo Vaz <lvaz@redhat.com>
>>> Fixes: 7f2d6b811755 ("xfs_repair: avoid segfault if reporting progre...")
>>> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
>>> ---
>> I've been looking at this myself, got stuck writing an xfstest, which this
>> passes, though the fix I was trying missed at least one of the formatters
>> that this fixes, and the log zeroing is a nice touch.
>>
>> Reviewed-by: Donald Douwsma <ddouwsma@redhat.com>
>
> Hm, serves you right for writing a validation test. ;) sorry :(
>
My fix ended up being a bit... primitive, so all good!
> But: "the fix I was trying missed at least one of the formatters
> that this fixes" - which one is that? I didn't think I fixed any existing
> thing.
Actually its probably my test that's a bit busted, I wanted to catch the
all of the formatting variations, but some are time sensitive, so its hit
second vs seconds and my filter didn't cope.
Ran: xfs/516
Failures: xfs/516
Failed 1 of 1 tests
[root@rhel7 xfstests-dev]# diff -u /root/Devel/upstream/xfstests-dev/tests/xfs/516.out /root/Devel/upstream/xfstests-dev/results//xfs/516.out.bad
--- /root/Devel/upstream/xfstests-dev/tests/xfs/516.out 2020-05-19 15:49:58.736465391 +1000
+++ /root/Devel/upstream/xfstests-dev/results//xfs/516.out.bad 2020-05-19 16:30:45.257220692 +1000
@@ -2,6 +2,7 @@
Format and populate
Introduce a dmdelay
Run repair
+ - #:#:#: Phase #: #% done - estimated remaining time # minutes, # second
- #:#:#: Phase #: #% done - estimated remaining time # minutes, # seconds
- #:#:#: Phase #: elapsed time # second - processed # inodes per minute
- #:#:#: Phase #: elapsed time # seconds - processed # inodes per minute
@@ -13,3 +14,4 @@
- #:#:#: scanning filesystem freespace - # of # allocation groups done
- #:#:#: setting up duplicate extent list - # of # allocation groups done
- #:#:#: verify and correct link counts - # of # allocation groups done
+ - #:#:#: zeroing log - # of # blocks done
prev parent reply other threads:[~2020-05-19 23:39 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-18 22:35 [PATCH] xfs_repair: fix progress reporting Eric Sandeen
2020-05-19 0:58 ` Darrick J. Wong
2020-05-19 1:03 ` Eric Sandeen
2020-05-19 1:13 ` Darrick J. Wong
2020-05-19 1:15 ` Eric Sandeen
2020-05-19 1:29 ` [PATCH V2] " Eric Sandeen
2020-05-19 2:04 ` Darrick J. Wong
2020-05-19 7:03 ` Donald Douwsma
2020-05-19 12:53 ` Eric Sandeen
2020-05-19 23:38 ` Donald Douwsma [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=caab376d-22b1-39cd-0b71-8ca2d1e4dc3d@redhat.com \
--to=ddouwsma@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=linux-xfs@vger.kernel.org \
--cc=lvaz@redhat.com \
--cc=sandeen@redhat.com \
--cc=sandeen@sandeen.net \
/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