Filesystem operations slower in 13.0 than 12.2

Kevin Oberman rkoberman at gmail.com
Sun Mar 14 00:33:17 UTC 2021


Just spent a little time looking at my issue and have a few more notes:

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"
>


More information about the freebsd-stable mailing list