--V88s5gaDVPzZ0KCq
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 15, 2007 at 10:05:26PM -0700, Scott Long wrote:
> Kostik Belousov wrote:
> >On Thu, Nov 15, 2007 at 11:16:02PM +0100, Kris Kennaway wrote:
> >>Kris Kennaway wrote:
> >>>I got this panic on an 8 core amd64 running 8.0 when writing to a ufs =

on=20
> >>>a md device:
> >>>
> >>>panic: ffs_reallocblk: start =3D=3D end
> >>>
> >>>db> wh
> >>>Tracing pid 59911 tid 100115 td 0xffffff0003b90000
> >>>kdb_enter() at kdb_enter+0x31
> >>>panic() at panic+0x1c0
> >>>ffs_reallocblks() at ffs_reallocblks+0xb11
> >>>VOP_REALLOCBLKS_APV() at VOP_REALLOCBLKS_APV+0xb9
> >>>cluster_write() at cluster_write+0x38a
> >>>ffs_write() at ffs_write+0x575
> >>>VOP_WRITE_APV() at VOP_WRITE_APV+0x147
> >>>vn_write() at vn_write+0x213
> >>>dofilewrite() at dofilewrite+0x9a
> >>>kern_writev() at kern_writev+0x4f
> >>>write() at write+0x4b
> >>>syscall() at syscall+0x301
> >>>Xfast_syscall() at Xfast_syscall+0xab
> >>>--- syscall (4, FreeBSD ELF64, write), rip =3D 0x800a65d0c, rsp =3D=20
> >>>0x7fffffffd268, rbp =3D 0x2800 ---
> >>>
> >>>Kris
> >>>
> >>Another one of these on a different machine. Looks like something is=

=20
> >>definitely broken.
> >>

> >Kris,
> >this is consequence of the checks moved from DIAGNOSTIC to INVARIANTS
> >ifdef for ffs, and actually being compiled as result. Peter Holm reported
> >the "ffs_truncate3" panic.

>=20
> So does this check identify a real problem that needs to be fixed?


I believe so for ffs_truncate3. It seems that vtruncbuf sometime skips the
indirect blocks when cleaning buffer queues (at least when truncating to
zero length).

--V88s5gaDVPzZ0KCq
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (FreeBSD)

iD8DBQFHPSeKC3+MBN1Mb4gRAmTPAJ9Byr61E+cE1B6kvErss4 5vtpLE+gCgnL1F
OtrDgyInVdmYPMQLooNb7xo=
=KbxK
-----END PGP SIGNATURE-----

--V88s5gaDVPzZ0KCq--