* [PATCH] ext4/021: make sure the fdatasync subprocess exits
@ 2020-02-14 2:20 zhangyi (F)
2020-02-23 12:34 ` Eryu Guan
0 siblings, 1 reply; 3+ messages in thread
From: zhangyi (F) @ 2020-02-14 2:20 UTC (permalink / raw)
To: fstests, guaneryu; +Cc: linux-ext4, yi.zhang
Now we just kill fdatasync_work process and wait nothing after the
test, so a busy unmount failure may appear if the fdatasync syscall
doesn't return in time.
umount: /tmp/scratch: target is busy.
mount: /tmp/scratch: /dev/sdb already mounted on /tmp/scratch.
!!! failed to remount /dev/sdb on /tmp/scratch
This patch kill and wait the xfs_io fdatasync subprocess to make sure
_check_scratch_fs success.
Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
---
tests/ext4/021 | 1 +
1 file changed, 1 insertion(+)
diff --git a/tests/ext4/021 b/tests/ext4/021
index 519737e1..1b4a1ced 100755
--- a/tests/ext4/021
+++ b/tests/ext4/021
@@ -18,6 +18,7 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
_cleanup()
{
+ $KILLALL_PROG -wq xfs_io
cd /
rm -f $tmp.*
}
--
2.23.0.rc2.8.gff66981f45
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] ext4/021: make sure the fdatasync subprocess exits
2020-02-14 2:20 [PATCH] ext4/021: make sure the fdatasync subprocess exits zhangyi (F)
@ 2020-02-23 12:34 ` Eryu Guan
2020-02-24 11:31 ` zhangyi (F)
0 siblings, 1 reply; 3+ messages in thread
From: Eryu Guan @ 2020-02-23 12:34 UTC (permalink / raw)
To: zhangyi (F); +Cc: fstests, linux-ext4
On Fri, Feb 14, 2020 at 10:20:01AM +0800, zhangyi (F) wrote:
> Now we just kill fdatasync_work process and wait nothing after the
> test, so a busy unmount failure may appear if the fdatasync syscall
> doesn't return in time.
>
> umount: /tmp/scratch: target is busy.
> mount: /tmp/scratch: /dev/sdb already mounted on /tmp/scratch.
> !!! failed to remount /dev/sdb on /tmp/scratch
>
> This patch kill and wait the xfs_io fdatasync subprocess to make sure
> _check_scratch_fs success.
Yeah, that's a problem.
I think you could add another "trap" in fdatasync_work, as what
btrfs/036 does:
trap "wait; exit" SIGTERM
So xfs_io will be waited by fdatasync_work before exiting.
Thanks,
Eryu
>
> Signed-off-by: zhangyi (F) <yi.zhang@huawei.com>
> ---
> tests/ext4/021 | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/ext4/021 b/tests/ext4/021
> index 519737e1..1b4a1ced 100755
> --- a/tests/ext4/021
> +++ b/tests/ext4/021
> @@ -18,6 +18,7 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>
> _cleanup()
> {
> + $KILLALL_PROG -wq xfs_io
> cd /
> rm -f $tmp.*
> }
> --
> 2.23.0.rc2.8.gff66981f45
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] ext4/021: make sure the fdatasync subprocess exits
2020-02-23 12:34 ` Eryu Guan
@ 2020-02-24 11:31 ` zhangyi (F)
0 siblings, 0 replies; 3+ messages in thread
From: zhangyi (F) @ 2020-02-24 11:31 UTC (permalink / raw)
To: Eryu Guan; +Cc: fstests, linux-ext4
Hi,
On 2020/2/23 20:34, Eryu Guan wrote:
> On Fri, Feb 14, 2020 at 10:20:01AM +0800, zhangyi (F) wrote:
>> Now we just kill fdatasync_work process and wait nothing after the
>> test, so a busy unmount failure may appear if the fdatasync syscall
>> doesn't return in time.
>>
>> umount: /tmp/scratch: target is busy.
>> mount: /tmp/scratch: /dev/sdb already mounted on /tmp/scratch.
>> !!! failed to remount /dev/sdb on /tmp/scratch
>>
>> This patch kill and wait the xfs_io fdatasync subprocess to make sure
>> _check_scratch_fs success.
>
> Yeah, that's a problem.
>
> I think you could add another "trap" in fdatasync_work, as what
> btrfs/036 does:
>
> trap "wait; exit" SIGTERM
>
> So xfs_io will be waited by fdatasync_work before exiting.
>
Thanks for your suggestion, I will do that.
Thanks,
Yi.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-02-24 11:49 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-14 2:20 [PATCH] ext4/021: make sure the fdatasync subprocess exits zhangyi (F)
2020-02-23 12:34 ` Eryu Guan
2020-02-24 11:31 ` zhangyi (F)
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).