From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bob Peterson Date: Tue, 28 May 2013 08:54:38 -0400 (EDT) Subject: [Cluster-devel] [GFS2 PATCH] GFS2: Set log descriptor type for jdata blocks In-Reply-To: <1369576275.2737.3.camel@menhir> References: <788202789.28848005.1369422169503.JavaMail.root@redhat.com> <1369576275.2737.3.camel@menhir> Message-ID: <1102208234.29508494.1369745678789.JavaMail.root@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ----- Original Message ----- | > This patch sets the log descriptor type according to whether the | > journal commit is for (journaled) data or metadata. This was | > recently broken when the functions to process data and metadata | > log ops were combined. | Thanks - looks good. If we can automatically detect the erroneous | entries, could we also automatically deal with those too? That might be | useful in case people already have such entries in their logs, | | Steve. Hi, Since the bad entries are data blocks, there's no good way to distinguish them from other kinds of corrupt metadata. We could make the code treat them as jdata rather than metadata instead of throwing the error, but I question whether it's worth it, since the problem will only present itself upon journal replay, and only on recent upstream kernels. The problem doesn't exist in RHEL6 or below. Removing our error checking in favor of treating the blocks as jdata would make it less effective at finding real metadata block corruption in the journals, and that seems like a check we should keep. Still, it's simple enough to do. Opinions? Regards, Bob Peterson Red Hat File Systems