Re: ffs_truncate3 panics

> Konstantin Belousov wrote:
> [stuff snipped]
> >> >Can you print the only buffer on the clean queue when the panic occur ?
> >> ffst3 vtyp=1 bodirty=0 boclean=1
> >> buf at 0x428a110
> >> b_flags = 0x20001020<vmio,reuse,cache>, b_xflags=0x2<clean>, b_vflags=0x0
> >> b_error = 0, b_bufsize = 4096, b_bcount = 4096, b_resid = 0
> >> b_bufobj = (0xfd8ba94), b_data = 0x5170000, b_blkno = -1, b_lblkno = -1, b_dep = 0
> >> b_kvabase = 0x5170000, b_kvasize = 32768
> >So the buffer was indeed for extended attrs, and never written to the disk.
> >I am quite interested what was the inode content prior to the truncation,
> >esp. the di_extsize.
> Just in case it wasn't clear, this buffer is on the clean list and not the dirty one.
> (Does this mean it somehow got onto the "clean list" without being written to disk?)
> 
> >Could you try to formulate a way to reproduce the panic so that Peter
> >can recreate it, please ?
> I doubt it. It would require him doing a pNFS setup with multiple systems.
> (At least that is the only way I reproduce it and I sometimes go a week of testing
>  before I see them.)
> It would be great to have more testers for the pNFS server stuff, but I doubt it
> would fit into Peter's setup?

It should be possible to design a set of VM's using bhyve, xen or ones
favorite hypervisor/virtulization platform to do "more" pNFS testing.
If you could provide a rought machine set needed to have a functional
test bed, and what should be done to "test" for problems I think it
should be possible to get you some addition testers.

Thanks,

> I can add printf()s anywhere you suggest, but I'm not sure how you would catch
> this case sooner? (For example, I could print out di_extsize at the beginning of
> ffs_truncate(), if that would help?)
> 
> rick
> [more stuff snipped]

-- 
Rod Grimes                                                 rgrimes_at_freebsd.org