xfs
[Top] [All Lists]

Re: [GIT PULL] XFS update for 2.6.23 - revert a commit

To: Timothy Shimmin <tes@xxxxxxx>
Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit
From: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>
Date: Wed, 3 Oct 2007 04:11:50 -0400 (EDT)
Cc: Lachlan McIlroy <lachlan@xxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4702F517.3040502@xxxxxxx>
References: <20071001072350.DF61C58C4C0A@xxxxxxxxxxxxxxxxxxxxxxx> <4700EE2A.1020304@xxxxxxxxxxx> <4701A1D0.5010709@xxxxxxx> <4701ED51.8050706@xxxxxxx> <Pine.LNX.4.64.0710020442540.24427@xxxxxxxxxxxxxxxx> <4702F517.3040502@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx


On Wed, 3 Oct 2007, Timothy Shimmin wrote:

Hi Justin,

Justin Piszcz wrote:


On Tue, 2 Oct 2007, Lachlan McIlroy wrote:

Yeah that about sums it up.  In an attempt to prevent log replay of inodes
in cases when we shouldn't replay we also prevented log replay of inodes in cases when we should replay. We end up with directories that refer to inodes
that were not replayed and we read existing data off disk.  That existing
data is usually previous instances of inodes. We had cases of regular files
turning into directories and inode version mismatches.

Lachlan

In 2.6.23-rc8?

The bad change went into rc7 and was still there in rc8.
It was backed out for rc9.

--Tim


If one with was running 2.6.23-rc8 with XFS, does that mean we should run xfs_repair on our filesystems after upgrading to -rc9?

Justin.


<Prev in Thread] Current Thread [Next in Thread>