Date: Wed, 12 Jul 2017 15:31:13 -0700 From: Mark Millard <markmi@dsl-only.net> To: peter@rulingia.com, Michael Butler <imb@protected-networks.net>, "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: FreeBSD Current <freebsd-current@freebsd.org>, linimon@FreeBSD.org Subject: Re: dump trying to access incorrect block numbers? Message-ID: <D0C95297-6EA0-4251-B8AB-29F9AD4FBB97@dsl-only.net> In-Reply-To: <F623CD27-CAD4-4FFF-9277-EF1DEFBDAABD@dsl-only.net> References: <D54716CF-02E7-4AC9-8E01-12465EC16966@dsl-only.net> <73E92033-CB2F-404C-8B3F-736EF09AA9F7@dsl-only.net> <F623CD27-CAD4-4FFF-9277-EF1DEFBDAABD@dsl-only.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I have extracted material from the list-exchanges related to this and submitted: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220693 against the kernel for the issue. I placed emphasis on the SSD-trim related "freeing free block" panics that "fsck -B" can lead to after it gets the g_vfs_done messages for unclean ufs file systems but first noted that: mksnap_ffs /.snap2 was enough to get the g_vfs_done messages. I figured that the nastiest and most important known consequences were "fsck -B" being broken for unclean ufs file systems and having later panics trying to trim based on how it is broken. I did also mention dump as producing the messages. I referenced. . . > See also the exchange of list submittals associated > with: > > https://lists.freebsd.org/pipermail/freebsd-current/2017-July/066505.html > > and: > > https://lists.freebsd.org/pipermail/freebsd-current/2017-July/066508.html === Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0C95297-6EA0-4251-B8AB-29F9AD4FBB97>