Filesystem operations slower in 13.0 than 12.2

Sun Mar 14 02:00:19 UTC 2021

On Sat, Mar 13, 2021 at 6:37 PM Kevin Oberman <rkoberman at gmail.com> wrote:

> I have been dealing with this for a long time since head back in September
> through 13-stable of Mar-4. I have seen no improvement over this time. It
> seems (my perception without supporting data) that it got worse in the
> timeframe of BETA-3 tag. I was running stable, so not quite BETA-3. It also
> does not help that I have also been bitten by the P-State related freeze
> issue which has some similarities. disabling p-states has almost eliminated
> this issue, though, with only three occurrences since I disabled them in
> late January.
>
>  As a result, I don't think it is a recent change, but a problem that has
> existed for at least 3 months. This was made worse by two hardware issues
> that kept the system unavailable for most of the time between buying it
> last spring and getting the keyboard replaced in January. (Both the
> mainboard and the disk drive had already been replaced.)  There was another
> slow I/O issue that I had assumed was the same as mine, but was reportedly
> fixed with BETA-4. A few are still seeing slow I/O, so I assume that there
> were different issues with I/O. Since CometLake systems seem pretty
> uncommon, it might be related to that.
>

It was a change from last fall, or set of changes. RC1 or defintely RC2 has
fixes to regain performance lost. If BETA4 was the last one you evaluated,
perhaps you could do a couple tests with RC2 now that it's out to see if it
is the same thing?

Warner

> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkoberman at gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
>
> On Sat, Mar 13, 2021 at 4:36 PM Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Sat, Mar 13, 2021 at 5:33 PM Kevin Oberman <rkoberman at gmail.com>
>> wrote:
>>
>>> Just spent a little time looking at my issue and have a few more notes:
>>>
>>
>> What version did you evaluate? There's a number of changes lately that
>> could have a big impact on this...
>>
>> Warner
>>
>>
>>> Seems to only occur on large r/w operations from/to the same disk. "sp
>>> big-file /other/file/on/same/disk" or tar/untar operations on large
>>> files.
>>> Hit this today updating firefox.
>>>
>>> I/O starts at >40MB/s. Dropped to about 1.5MB/s. If I tried doing other
>>> things while it was running slowly, the disk would appear to lock up.
>>> E.g.
>>> pwd(1) seemed to completely lock up the system, but I could still ping it
>>> and, after about 30 seconds, things came back to life. It was also not
>>> instantaneous. Disc activity dropped to <1MB/s for a few seconds before
>>> everything froze.
>>>
>>> During the untar of firefox, I saw; this several times. I also looked at
>>> my
>>> console where I found these errors during :
>>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 55043, size: 8192
>>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 51572, size: 4096
>>>
>>> I should note that some operations continue just fine while this is going
>>> on until I do something that freezes the system. I assume that this
>>> eliminates the disk drive and low-level driver. Is vfs a possible issue.
>>> It
>>> had some serious work in the past few months by markj. That does not
>>> explain why more people are not seeing this.
>>>
>>> I have been seeing this since at least September 2020, so it goes back a
>>> way. As this CometLake system will not run graphics on 12, I can't
>>> confirm
>>> operation before 13.
>>> --
>>> Kevin Oberman, Part time kid herder and retired Network Engineer
>>> E-mail: rkoberman at gmail.com
>>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>>
>>>
>>> On Fri, Mar 5, 2021 at 10:47 PM Mark Millard via freebsd-stable <
>>> freebsd-stable at freebsd.org> wrote:
>>>
>>> >
>>> > Konstantin Belousov kostikbel at gmail.com wrote on
>>> > Fri Mar 5 23:12:13 UTC 2021 :
>>> >
>>> > > On Sat, Mar 06, 2021 at 12:27:55AM +0200, Christos Chatzaras wrote:
>>> > . . .
>>> > > > Command: /usr/bin/time -l portsnap extract (these tests done with 2
>>> > different idle servers but with same 4TB HDDs models)
>>> > > >
>>> > > > FreeBSD 12.2p4
>>> > > >
>>> > > >        99.45 real        34.90 user        59.63 sys
>>> > > >       100.00 real        34.91 user        59.97 sys
>>> > > >        82.95 real        35.98 user        60.68 sys
>>> > > >
>>> > > > FreeBSD 13.0-RC1
>>> > > >
>>> > > >       217.43 real        75.67 user       110.97 sys
>>> > > >       125.50 real        63.00 user        96.47 sys
>>> > > >       118.93 real        62.91 user        96.28 sys
>>> > > . . .
>>> > > In the portsnap results for 13RC1, the variance is too high to
>>> conclude
>>> > > anything, I think.
>>> >
>>> > I'll note that there are other reports of wide variance
>>> > in transfer rates observed during an overall operation
>>> > such as "make extract". The one I'm thinking of is:
>>> >
>>> >
>>> https://lists.freebsd.org/pipermail/freebsd-stable/2021-March/093251.html
>>> >
>>> > which is an update to earlier reports, but based on more recent
>>> > stable/13. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253968
>>> > comment 4 has some more notes about the context. The "make extract"
>>> > for firefox likely is not as complicated as the portsnap extract
>>> > example's execution structure.
>>> >
>>> > Might be something to keep an eye on if there are on-going
>>> > examples of over time.
>>> >
>>> > ===
>>> > Mark Millard
>>> > marklmi at yahoo.com
>>> > ( dsl-only.net went
>>> > away in early 2018-Mar)
>>> >
>>> > _______________________________________________
>>> > freebsd-stable at freebsd.org mailing list
>>> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> > To unsubscribe, send any mail to "
>>> freebsd-stable-unsubscribe at freebsd.org"
>>> >
>>> _______________________________________________
>>> freebsd-stable at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at freebsd.org
>>> "
>>>
>>