| 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 inodesin 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 inodesthat were not replayed and we read existing data off disk. That existingdata is usually previous instances of inodes. We had cases of regular filesturning into directories and inode version mismatches. LachlanIn 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. |
| Previous by Date: | Re: REVIEW: xfs_reno, David Chinner |
|---|---|
| Next by Date: | Re: [PATCH] Replace XFS bit functions with Linux functions, Andi Kleen |
| Previous by Thread: | Re: [GIT PULL] XFS update for 2.6.23 - revert a commit, Timothy Shimmin |
| Next by Thread: | Re: [GIT PULL] XFS update for 2.6.23 - revert a commit, David Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |