[This note has more information than one sent with extra text in the subject but with a partially different "to" list.]
Peter Jeremy peter at rulingia.com wrote on Sat Jul 8 02:00:47 UTC 2017 : > When did you first notice this (what SVN revision)? > Do you know what the last good SVN revision was? > Is this a new or old filesystem? > Is the filesystem mounted/active or not when you dump it? > What are the relevant parameters for the filesystem on ada0s3a? > Are you running softupdates, journalling etc? > Which dump(8) phase is reporting the errors? > What are the exact dump and fsck commands you ran? I can add a little information with some contrast and only "fsck -B" in use (with an unclean file system from a prior crash), no dump use. Still: a snapshot is involved in the below. Unfortunately two problems with major consequences for my involved context limit the svn range that I can cover for the activity, the problem version ranges being: -r319722 through -r320651 (fixed by -r320652) (actually this is why I had used "boot -s" in what I report later: I could get to a shell prompt that way instead of crashing before any login prompt; the crashes left the file system in need of repair) -r320509 through -r320561 (fixed by -r320570) So I was using -r320570 to avoid one of the two problems. Context: 32-bit powerpc FreeBSD used on PowerMac G5 so-called "Quad-core". (So big-endian as well.) Softupdates, no journalling. Long-in-use file system having lots of FreeBSD versions updates and port rebuilds over the time. The following is from now, not from the time of the example messages: # dumpfs / | more magic 19540119 (UFS2) time Fri Jul 7 22:53:34 2017 superblock location 65536 id [ <OMITTED> ] ncg 158 size 25165823 blocks 24372006 bsize 32768 shift 15 mask 0xffff8000 fsize 4096 shift 12 mask 0xfffff000 frag 8 shift 3 fsbtodb 3 minfree 8% optim time symlinklen 120 maxbsize 32768 maxbpg 4096 maxcontig 4 contigsumsize 4 nbfree 2130375 ndir 65518 nifree 11769796 nffree 425065 bpg 20032 fpg 160256 ipg 80128 unrefs 0 nindir 4096 inopb 128 maxfilesize 2252349704110079 sbsize 4096 cgsize 32768 csaddr 5048 cssize 4096 sblkno 24 cblkno 32 iblkno 40 dblkno 5048 cgrotor 127 fmod 0 ronly 0 clean 0 metaspace 6408 avgfpdir 64 avgfilesize 16384 flags soft-updates trim fsmnt / volname FBSDG4Srootfs swuid 0 providersize 25165823 . . . What I had done that produced the messages was: <Prior failed multi-user boot from system problem leaves root (only) file system not marked clean so fsck -B will actually do something below> boot -s (so: single user mode) # The next 3 lines are the content of a generic, manually-run script. mount -u / mount -a -t ufs (but there is no other file system) swapon -a (there is a swap partition) # fsck -B That "fsck -B" caused the same kinds of lines reported by Michael Butler, happening as fsck makes a snapshot for the background processing to use. (I have camera pictures and could type in some of the lines if needed.) After those lines was text like (typed in from an example camera picture): ** //.snap/fsck_snapshot ** Last Mount on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups Reclaimed: 0 directories, 1 files, 22680 fragments 780914 files, 4797127 used, 19552199 free (443479 frags, 3288590 blocks, 1.8% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** === Mark Millard markmi at dsl-only.net _______________________________________________ firstname.lastname@example.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"