Re: system freeze on "slice too large"

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:This is an old kernel, no new labels here.
:
:...
:yes.
:
:>  - was your volume set created prior to upgrading past the disklabel
:>    changes?
:
:it was created about 3 years ago, I think.
:
:>  - is this an occasional crash, or a constant one?
:
:it happened two times, within 12 hours or so.
:
:cheers
:  simon

    I think there are two different issues here.  This issue:

:i've now had twice a nasty freeze (kind of) with something like this (hand trans
:cribed):
:
:dscheck(#ad/0x20021): slice too large 2/2
:..

    Is simply vinum trying to access e.g. ad0s2 when ad0 is dangerously
    dedicated (i.e. only ad0s0 exists).  When does it do this?  This only
    happens to me when I try to have vinum auto-start.

:then vinum tells me that it put "build" down and continues:
:
:fatal: build.p0.s0 read error, offset 33831591936 for 4096 bytes
:build.p0.s0: user buffer offset 10209280000 for 4096 bytes
:
:(more slice too large follow)
:
:then, the namecache does
:
:blocked on 0xd4fb7b58 "corecode"

    Read error sounds like a real read error.  Is that a valid offset?
    It's a byte offset, not a sector number.  Is there any disk redundancy?

    I'm not sure what the two offsets are.  They must be relative to
    different things.  The first is probably relative to the vinum volume
    while the scond looks like it may be partition-relative.

    A real read error can cause UFS to get confused and create a namecache
    blockage.

						-Matt