Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Sep 2017 12:58:58 +0200
From:      Gary Jennejohn <gljennjohn@gmail.com>
To:        Andreas Longwitz <longwitz@incore.de>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: fsync: giving up on dirty on ufs partitions running vfs_write_suspend()
Message-ID:  <20170921125858.64ffe077@ernst.home>
In-Reply-To: <59C37F46.80509@incore.de>
References:  <201709110519.v8B5JVmf060773@chez.mckusick.com> <59BD0EAC.8030206@incore.de> <20170916183117.GF78693@kib.kiev.ua> <59C37F46.80509@incore.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Sep 2017 10:58:46 +0200
Andreas Longwitz <longwitz@incore.de> wrote:

[snip]
> I have checked your proposal and found that indeed the
> mnt_secondary_writes counter goes to zero when the dirties have reached
> zero. During the loop the mnt_secondary_write counter is always equal to
> one, so there is not something like a countdown and thats Kirk wanted to
> see. A dtrace output (with DELAY of 1ms in the loop) for the biggest
> loop count on a three day test is this:
> 
>  18  32865      kern_unlinkat:entry    path=bigfile, tid=101201,
> tid=101201, execname=rm
>  18  12747         ufs_remove:entry    gj=mirror/gmbkp4p5.journal,
> inum=11155630, blocks=22301568, size=11415525660
>  18  12748        ufs_remove:return    returncode=0, inum=11155630,
> blocks=22301568
>  18  18902       ffs_truncate:entry    gj=mirror/gmbkp4p5.journal,
> inum=11155630, size=11415525660, mnt_flag=0x12001040,
> mnt_kern_flag=0x40006142, blocks=22301568
>   6  33304  vfs_write_suspend:entry    gj=mirror/gmbkp4p5.journal,
> mnt_kern_flag=0x40006142, tid=100181
>   6  22140       vop_stdfsync:entry    mounted on /home, waitfor=1,
> numoutput=0, clean=10, dirty=6, secondary_writes=1
>  10  28117      bufobj_wwait:return    calls to bufobj_wait = 1,
> dirtycnt=2, secondary_writes=1
>  10  28117      bufobj_wwait:return    calls to bufobj_wait = 2,
> dirtycnt=1, secondary_writes=1
>  10  28117      bufobj_wwait:return    calls to bufobj_wait = 3,
> dirtycnt=1, secondary_writes=1
>  10  28117      bufobj_wwait:return    calls to bufobj_wait = 4,
> dirtycnt=3, secondary_writes=1
>  10  28117      bufobj_wwait:return    calls to bufobj_wait = 5,
> dirtycnt=2, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 6,
> dirtycnt=3, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 7,
> dirtycnt=3, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 8,
> dirtycnt=3, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 9,
> dirtycnt=3, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 10,
> dirtycnt=2, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 11,
> dirtycnt=2, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 12,
> dirtycnt=3, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 13,
> dirtycnt=3, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 14,
> dirtycnt=3, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 15,
> dirtycnt=4, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 16,
> dirtycnt=3, secondary_writes=1
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 17,
> dirtycnt=3, secondary_writes=1
>   2  18903      ffs_truncate:return    returncode=0, inum=11155630, blocks=0
>   2  32866     kern_unlinkat:return    returncode=0, errno=0, number
> io's: 791/791
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 18,
> dirtycnt=3, secondary_writes=0
>   6  28117      bufobj_wwait:return    calls to bufobj_wait = 19,
> dirtycnt=0, secondary_writes=0
>   6  22141      vop_stdfsync:return    returncode=0, pid=26, tid=100181,
> spent 240373850 nsecs
> 
> So the spent time in vop_stdfsync() is 0,24 sec in the worst case I
> found using DELAY with 1 ms. I would prefer this solution. My first
> appoach (simple bumping maxres from 1000 to 100000) is also ok, but max
> spend time will be raise up to 0,5 sec. Perhaps you like something like
> 
>    if( maxretry < 1000 && maxretry % 10 = 0)
                                                                    ^ ==
>           DELAY(waitns);
> 

The argument to DELAY is in micro-seconds.

-- 
Gary Jennejohn



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170921125858.64ffe077>