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 > >>>a md device: > >>> > >>>panic: ffs_reallocblk: start == 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 = 0x800a65d0c, rsp = > >>>0x7fffffffd268, rbp = 0x2800 --- > >>> > >>>Kris > >>> > >>Another one of these on a different machine. Looks like something is > >>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. > > 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).
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:22 UTC