dump trying to access incorrect block numbers?

[Rodney W. Grimes]

> On 07/07/17 21:53, Peter Jeremy wrote:
> > On 2017-Jul-07 10:44:36 -0400, Michael Butler <imb at protected-networks.net> wrote:
> >> Recent builds doing a backup (dump) cause nonsensical errors in syslog:
> > 
> > I can't directly offer any ideas but some more background might help:
> > When did you first notice this (what SVN revision)?
> 
> I was stuck on SVN r319721 on the i386 machine while the socket/union 
> issue was addressed. That version did not display the problem.
> 
> > Do you know what the last good SVN revision was?
> > Is this a new or old filesystem?
> 
> old - it's been years since this system was rebuilt.
> 
> > Is the filesystem mounted/active or not when you dump it?
> 
> Mounted and active.
> 
> > What are the relevant parameters for the filesystem on ada0s3a?
> 
> imb at toshi:/home/imb> dumpfs /
> 
> magic   19540119 (UFS2) time    Fri Jul  7 22:43:49 2017
> superblock location     65536   id      [ 56c8bf68 1a8b12b5 ]
> ncg     516     size    82575360        blocks  79978821
> 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  3965346 ndir    98169   nifree  40196026        nffree  453383
> bpg     20035   fpg     160280  ipg     80256   unrefs  0
> nindir  4096    inopb   128     maxfilesize     2252349704110079
> sbsize  4096    cgsize  32768   csaddr  5056    cssize  12288
> sblkno  24      cblkno  32      iblkno  40      dblkno  5056
> cgrotor 253     fmod    0       ronly   0       clean   0
> metaspace 6408  avgfpdir 64     avgfilesize 16384
> flags   soft-updates
> fsmnt   /
> volname         swuid   0       providersize    82575360
> 
>   [ .. ]
> 
> > Are you running softupdates, journalling etc?
> 
> soft-updates only.
> 
> > Which dump(8) phase is reporting the errors?
> 
> The errors occur before the "date of the last level x dump" message - 
> presumably, this is while creating the snapshot.
> 
> > What are the exact dump and fsck commands you ran?
> 
> /sbin/dump 0Lauf - -C 32 /
> 
> none of the following report any (unexpected) errors:
> 
> fsck -f /
> fsck -f -r /
> fsck -f -Z /
> 
> > 
> >> I now have two UFS-based systems showing the same symptoms - what's up
> >> with this?
> > 
> > Was there anything you did on either filesystem that might have triggered it?
> 
> Other than update the kernel, no.

Since it has been speculated that this is occuring during the
creation of the snapshot, could you try just creating a snapshot
using mksnap_ffs and see if any errors occur?


-- 
Rod Grimes                                                 rgrimes at freebsd.org