ffs_truncate3 panics

[Konstantin Belousov]

On Tue, Aug 07, 2018 at 12:28:33PM +0000, Rick Macklem wrote:
> Hi,
> 
> During testing of the pNFS server I get an ffs_truncate3 panic every once in a while.
> A few things that might be relevant:
> - Seems to happen more often when soft update journaling is enabled, but will
>   happen when it is disabled.
> - Normally happens when a fairly large subtree of the file system is being removed.
> 
> These file systems are a bit odd, since all the regular files in them are empty but
> have extended attributes that are accessed during the subtree removal. (The
> extended attributes tell the server where the data files are.)
> 
> I replaced the panic() with a printf() and every time the printf() happens...
> bo->bo_dirty.bv_cnt == 0 and bo->bo_clean.bv_cnt == 1.
> After one of these printf()s, the system continues to run ok. When the file
> system is fsck'd after this has occurred, it passes fine and I haven't seen and
> indication of file system corruption after running with this file system for
> quite a while after the printf()s first occurred.
The lack of corruption is, most likely, because the files are removed.
Would the files truncated to zero length and then extended, I am almost
sure that a corruption occur.

Can you print the only buffer on the clean queue when the panic occur ?
Also, it is interesting to know the initial length of the file.

> 
> Since the panic() only occurs when "options INVARIANTS" is enabled and I don't
> see evidence of file system corruption, I'm wondering if this panic() is valid and
> needed?
> 
> rick
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"