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

From: Mark Millard <markmi_at_dsl-only.net>
Date: Fri, 7 Jul 2017 17:02:25 -0700
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 (_at_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
Received on Fri Jul 07 2017 - 22:02:38 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:12 UTC