[Top] [All Lists]

Re: Problem with XFS on USB 2TB HD

To: Kevin Richter <xfs@xxxxxxxxxxx>
Subject: Re: Problem with XFS on USB 2TB HD
From: Geoffrey Wehrman <gwehrman@xxxxxxx>
Date: Thu, 13 Jan 2011 15:52:28 -0600
Cc: xfs@xxxxxxxxxxx
In-reply-to: <4D2E3B38.6010506@xxxxxxxxxxx>
References: <4D0C9A4F.4040108@xxxxxxxxxxx> <20101220001024.GH5193@dastard> <4D0EC5C5.2070407@xxxxxxxxxxx> <20101220045126.GK5193@dastard> <20101220105547.4f9e7218@xxxxxxxxxxxxxx> <4D2E3B38.6010506@xxxxxxxxxxx>
User-agent: Mutt/1.5.14 (2007-02-12)
On Thu, Jan 13, 2011 at 12:37:28AM +0100, Kevin Richter wrote:
| > That's because you had the misfortune of garbling the root directory
| > inode along with the superblock. That's a very specific corruption,
| > but if the corruption occurred a few blocks away in a data extent
| > you wouldn't even know about it until you restore from backup and
| > realised the file content in the backup are corrupted. Indeed - you
| > should consider that entire backup as corrupted and redo it from
| > scratch.
| I am wondering if there is a simple solution to backup/restore the inode
| table (the relation "inode <-> filename").
| With "ls -aliR" I get a list which I am now saving every few days.
| The parameter "-i" displays the inode, that I can reconstruct the
| filename from the inode, if this garbling error occurs a second time.
| The reconstruction process probably would be a simple "grep | cut" thing.
| Is there perhaps a finished script doing exactly this? Or any other ideas?

xfs_ncheck(8) will generate the patname/inode mapping, but does not
provide a restore service.

Geoffrey Wehrman

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