xfs
[Top] [All Lists]

Re: REVIEW: xfs_repair fixes for bad directories

To: "Christoph Hellwig" <hch@xxxxxxxxxxxxx>
Subject: Re: REVIEW: xfs_repair fixes for bad directories
From: "Barry Naujok" <bnaujok@xxxxxxx>
Date: Tue, 26 Aug 2008 12:08:27 +1000
Cc: "xfs@xxxxxxxxxxx" <xfs@xxxxxxxxxxx>
In-reply-to: <20080701081306.GA11135@xxxxxxxxxxxxx>
Organization: SGI
References: <op.udlsirmx3jf8g2@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080701081306.GA11135@xxxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Opera Mail/9.51 (Win32)
On Tue, 01 Jul 2008 18:13:06 +1000, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:

On Tue, Jul 01, 2008 at 06:00:17PM +1000, Barry Naujok wrote:
Two issues have been encounted with xfs_repair and badly corrupted
directories.

1. A huge size (inode di_size) can cause malloc which will fail.
   Patch dir_size_check.patch checks for a valid directory size
   and if it's bad, junks the directory. The di_size for a dir
   only counts the data blocks being used, not all the other
   associated metadata. This is limited to 32GB by the
   XFS_DIR2_LEAF_OFFSET value in XFS. Anything greater than this
   must be invalid.

This one looks good.

2. An update a while ago to xfs_repair attempts to fix invalid
   ".." entries for subdirectories where there is a valid parent
   with the appropriate entry. It was a partial fix that never
   did the full job, especially if the subdirectory was short-
   form or it has already been processed.

   Patch fix_dir_rebuild_without_dotdot_entry.patch creates a
   post-processing queue after the main scan to update any
   directories with an invalid ".." entry.

For this one I'll need to read the surrounding code first to do
a useful review, so it'll take some time.

Ping?



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