An FYI for 32-bit powerpc: : fsync: giving up on dirty [1st time Ive seen such messages]

[Mark Millard]

While ports-mgmt/poudreire-devel was attempting a build of llvm80
on an old PowerMac G5 [2 sockets, 2 cores each] but running 32-bit
FreeBSD, the system reported:

Mar 10 00:41:56 FBSDG4S kernel: fsync: giving up on dirty (error = 35) 0x23ae000: tag devfs, type VCHR
Mar 10 00:41:56 FBSDG4S kernel:     usecount 1, writecount 0, refcount 55 rdev 0x248e400
Mar 10 00:41:56 FBSDG4S kernel:     flags (VI_ACTIVE)
Mar 10 00:41:56 FBSDG4S kernel:     v_object 0x23582a0 ref 0 pages 2106 cleanbuf 40 dirtybuf 13
Mar 10 00:41:56 FBSDG4S kernel:     lock type devfs: EXCL by thread 0x229ac3a0 (pid 74842, pkg-static, tid 100224)
Mar 10 00:41:56 FBSDG4S kernel:         dev ufs/FBSDG4Srootfs
Mar 10 00:43:31 FBSDG4S kernel: fsync: giving up on dirty (error = 35) 0x23ae000: tag devfs, type VCHR
Mar 10 00:43:31 FBSDG4S kernel:     usecount 1, writecount 0, refcount 42 rdev 0x248e400
Mar 10 00:43:31 FBSDG4S kernel:     flags (VI_ACTIVE)
Mar 10 00:43:31 FBSDG4S kernel:     v_object 0x23582a0 ref 0 pages 12562 cleanbuf 27 dirtybuf 12
Mar 10 00:43:31 FBSDG4S kernel:     lock type devfs: EXCL by thread 0x229ac3a0 (pid 74842, pkg-static, tid 100224)
Mar 10 00:43:31 FBSDG4S kernel:  with exclusive waiters pending
Mar 10 00:43:31 FBSDG4S kernel:         dev ufs/FBSDG4Srootfs
Mar 10 00:45:21 FBSDG4S kernel: fsync: giving up on dirty (error = 35) 0x23ae000: tag devfs, type VCHR
Mar 10 00:45:21 FBSDG4S kernel:     usecount 1, writecount 0, refcount 57 rdev 0x248e400
Mar 10 00:45:21 FBSDG4S kernel:     flags (VI_ACTIVE)
Mar 10 00:45:21 FBSDG4S kernel:     v_object 0x23582a0 ref 0 pages 2930 cleanbuf 30 dirtybuf 24
Mar 10 00:45:21 FBSDG4S kernel:     lock type devfs: EXCL by thread 0x229ac3a0 (pid 74842, pkg-static, tid 100224)
Mar 10 00:45:21 FBSDG4S kernel:  with exclusive waiters pending
Mar 10 00:45:21 FBSDG4S kernel:         dev ufs/FBSDG4Srootfs

error=35 being FreeBSD's EAGAIN.

This seems to be from:

        /*
         * If synchronous the caller expects us to completely resolve all
         * dirty buffers in the system.  Wait for in-progress I/O to
         * complete (which could include background bitmap writes), then
         * retry if dirty blocks still exist.
         */
        if (ap->a_waitfor == MNT_WAIT) {
                bufobj_wwait(bo, 0, 0);
                if (bo->bo_dirty.bv_cnt > 0) {
                        /*
                         * If we are unable to write any of these buffers
                         * then we fail now rather than trying endlessly
                         * to write them out.
                         */
                        TAILQ_FOREACH(bp, &bo->bo_dirty.bv_hd, b_bobufs)
                                if ((error = bp->b_error) != 0)
                                        break;
                        if ((mp != NULL && mp->mnt_secondary_writes > 0) ||
                            (error == 0 && --maxretry >= 0))
                                goto loop1;
                        if (error == 0)
                                error = EAGAIN;
                }
        }
        BO_UNLOCK(bo);
        if (error != 0)
                vn_printf(vp, "fsync: giving up on dirty (error = %d) ", error);


However, old PowerMac G5s currently require some form of hack in order
to avoid sleeps getting stuck as things are. For all I know the messages
could be tied to that context in some way.

I've not seen such from 64-bit FreeBSD with 16 GiBytes of RAM on the
same G5.

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)