xfs
[Top] [All Lists]

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

To: Lachlan McIlroy <lachlan@xxxxxxx>
Subject: Re: [GIT PULL] XFS update for 2.6.23 - revert a commit
From: David Chinner <dgc@xxxxxxx>
Date: Tue, 2 Oct 2007 19:36:29 +1000
Cc: Timothy Shimmin <tes@xxxxxxx>, Eric Sandeen <sandeen@xxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4701ED51.8050706@xxxxxxx>
References: <20071001072350.DF61C58C4C0A@xxxxxxxxxxxxxxxxxxxxxxx> <4700EE2A.1020304@xxxxxxxxxxx> <4701A1D0.5010709@xxxxxxx> <4701ED51.8050706@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Tue, Oct 02, 2007 at 05:03:45PM +1000, 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.

The issue that started tripping this was stale inodes from a
previous filesystem being detected as valid clusters of inodes.
Hence inodes magically changed from what they were supposed to
be and that caused all sorts of problems.

FWIW, in a past life XFS was supposed to store the uuid of the
filesystem in it's inodes to prevent exactly this sort of confusion,
but that was considered expendable and disappeared in version 2
inodes when XFS grew 32bit link counts and project ID's. The padding
is still there waiting to be used.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group


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