Re: ffs_truncate3 panics

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Thu, 9 Aug 2018 01:39:20 +0000
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?

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]
Received on Wed Aug 08 2018 - 23:39:23 UTC

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