xfs
[Top] [All Lists]

Re: [PATCH] log replay should not overwrite newer ondisk inodes

To: Vlad Apostolov <vapo@xxxxxxx>
Subject: Re: [PATCH] log replay should not overwrite newer ondisk inodes
From: David Chinner <dgc@xxxxxxx>
Date: Mon, 3 Sep 2007 18:49:16 +1000
Cc: David Chinner <dgc@xxxxxxx>, Mark Goodwin <markgw@xxxxxxx>, Lachlan McIlroy <lachlan@xxxxxxx>, Timothy Shimmin <tes@xxxxxxx>, xfs-dev <xfs-dev@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
In-reply-to: <46DB3E4B.3030106@xxxxxxx>
References: <46D6279F.40601@xxxxxxx> <46D6480F.4040307@xxxxxxx> <46D64CAD.6050705@xxxxxxx> <46D67FE6.20205@xxxxxxx> <46D68510.1020404@xxxxxxx> <46D77B79.3040104@xxxxxxx> <46D792A1.7030308@xxxxxxx> <20070831154822.GD734179@xxxxxxx> <46DB3E4B.3030106@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.4.2.1i
On Mon, Sep 03, 2007 at 08:50:51AM +1000, Vlad Apostolov wrote:
> David Chinner wrote:
> >An unlinked inode is only detectable by the mode parameter being zero.
> >The rest of the inode will look valid.
> What about the nlink count? Can't we detect unlinked inode by nlink == 0?

A file that is open but unlinked must still remain valid on disk
until the last reference goes away. This inode will have a link
count of zero, but it is still a valid, referenced inode. Hence
detection of an inode with a link count of zero does not mean it
has been fully removed yet - a zero link count and a non-zero
mode indicates the inode should be onthe unlinked inode list.

See xfs_ifree() - the mode is zeroed only after the inode has been
pulled from the AGI unlinked list and marked free in the AGI btree.

Cheers,

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


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