| To: | xfs@xxxxxxxxxxx |
|---|---|
| Subject: | xfsrestore: incorrect restore if file becomes a dir |
| From: | David Brown <davidb@xxxxxxxxxx> |
| Date: | Mon, 26 Dec 2011 12:18:56 -0800 |
| Dkim-signature: | v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:subject:message-id :mime-version:content-type; s=smtpout; bh=+EuDcvvCtf1zTVLZ2cou8J 8ClzQ=; b=jkkYjxW/WKWd9P9+5iBaP/0bKeEDV4r5i1TwHV/LDRMRnDtdbabsDg TLNXra+6GZQxvdXdwogEvoc7NyoANcPcuCvuol+9rjH1+tSxdi7eWOe1TPFXL2k5 gd2WxOzR+T5HZC+cYks85sbxn2nqRHP9Yo+lmkxgxXXyYcEI8+DuY= |
| User-agent: | Mutt/1.5.21 (2010-09-15) |
http://oss.sgi.com/bugzilla/show_bug.cgi?id=915 I've had this happen again. It appears to be the case if between incremental dumps, a file is deleted and a directory is created that gets the same inode number. The restore leaves a file in place of the directory. If the new directory has any contents, xfsrestore prints a warning, and doesn't restore the subdirectory contents. Given the sparseness of inodes, this doesn't seem to occur all that frequently, but I do have a couple of backups that exhibit the behavior. If no one has any ideas, I'll start digging through xfsrestore to see if I can figure out what is happening. Thanks, David Brown |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH 2/2 v2] xfs: log all dirty inodes in xfs_fs_sync_fs, Dave Chinner |
|---|---|
| Next by Date: | [PATCH] Introduce SEEK_DATA/SEEK_HOLE support to XFS V4, Jeff Liu |
| Previous by Thread: | Merry Chrismas and Happy New Year!, Dong De Laser |
| Next by Thread: | [PATCH] Introduce SEEK_DATA/SEEK_HOLE support to XFS V4, Jeff Liu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |