dump trying to access incorrect block numbers? [It is not just dump that can get such]

[Mark Millard]

On 2017-Jul-7, at 4:49 PM, Michael Butler <imb at protected-networks.net> wrote:

> On 07/07/17 19:02, Mark Millard wrote:
>> Michael Butler imb at protected-networks.net  wrote on
>> Fri Jul 7 14:45:12 UTC 2017 :
>>> Recent builds doing a backup (dump) cause nonsensical errors in syslog:
>>> 
>>> Jul  7 00:10:24 toshi kernel:
>>> g_vfs_done():ada0s3a[READ(offset=6050375794688, length=32768)]error = 5
>>> Jul  7 00:10:24 toshi kernel:
>>> g_vfs_done():ada0s3a[READ(offset=546222112768, length=32768)]error = 5
>>> Jul  7 00:10:24 toshi kernel:
> 
> [ snip ]
> 
>> Both dump and fsck likely are using snapshots
>> so the issue is likely ties to ufs snapshots.
>> May be it has a INO64 incompleteness that
>> gives the huge offsets. (Wild guess.)
>> If your context was more typical then the issue
>> spans little-endian and big-endian since the
>> powerpc context is big-endian but most usage
>> is little endian.
> 
> I'm seeing this on both amd64 and i386 builds (@SVN r320760) when dump tries to build a snap-shot. These are both non-debug, non-invariant production boxes

Sounds like there is enough evidence of repeatability,
span of TARGET_ARCH's and systems, and recent enough
range of -r320??? vintages for a bugzilla submittal.

Your TARGET_ARCH's are more main-stream then where I've
tried something that showed the issue. What to do the
initial submittal?

===
Mark Millard
markmi at dsl-only.net