Re: [RFC 00/17] RFC parent inode pointers.

[Geoffrey Wehrman <gwehrman@sgi.com>]

On Tue, Feb 04, 2014 at 11:09:44AM +1100, Dave Chinner wrote:
| On Tue, Jan 28, 2014 at 04:02:30PM -0600, Geoffrey Wehrman wrote:
| > On Tue, Jan 28, 2014 at 02:00:40PM +1100, Dave Chinner wrote:
| > | On Mon, Jan 27, 2014 at 01:41:47PM -0600, Mark Tinguely wrote:
| > | > 2) Add the filename to EA. Not a fan, but I will ask but if DMF needs it
| > | >    for performance then it has to be done. My point was this assumes
| > | >    that we can keep all the links' EA entries inline in the inode. A
| > | >    couple 255 character files or several links of modest sized filenames
| > | >    would negate that assumption. I tried to minimize the EA entries to
| > | >    keep them inline in the inode. I will talk to the DMF group.
| > | 
| > | Actually, I made the point about DMF needing them inline performance
| > | because that's an argument SGI might find persuasive. What I didn't
| > | say just then is that *I* need them inline, too, as online directory
| > | tree scrubbing needs to be able to do bulks scans, as does
| > | xfs_repair. However, I have idefinitely said this before in previous
| > | parent poitner discussions, so it should be no surprise here...
| > 
| > I appologize in advance for my ignorance.  What is "online directory
| > tree scrubbing" and how does it benefit from parent inode pointers?
| 
| It will be a kernel thread that walks the directory tree
| periodically verifying that all inodes are reachable and that the
| directory tree is intact. It's the same principle as RAID array
| media scrubbing - proactive detection of errors that could cause
| failures and repairing them before an error is delivered to the
| application. The reason for wanting parent pointers is that it
| enables immediate repair of most corruptions as the scrubbing
| detects them without requiring duplicate copies of the metadata.
| 
| IOWs, parent pointers are a fundamental part of bringing on-line
| repair functionality to XFS. While parent pointers are not directly
| mentioned in this document:
| 
| http://xfs.org/index.php/Reliable_Detection_and_Repair_of_Metadata_Corruption
| 
| There is a section on reverse mapping for used blocks and how to use
| that for online repair of detected damage. Parent pointers provide
| reverse mappings for the directory structure, and hence provide the
| same functionality. Parent pointers also means that if we get an IO
| error in a block in a file, we can identify the owner of the block
| by full path and offset into the file where the error has
| occurred...
| 
| The v5 metadata format has an owner field in all metadata that has a
| single parent object for keeping such parent information, and it is
| intended for improving scrub-based validation and for identifying
| the owner of lost metadata blocks to improve recover from errors.
| i.e. reverse mapping is a one of the fundamental architectural
| requirements underlying the v5 metadata changes.
| 
| The two missing pieces are the parent pointers for directory
| structure reverse mapping, and an AGF reverse mapping btree to
| enable arbitrary block->owner lookups. I have prototype code for the
| AGF rmap btree, and the parent pointers provide that functionality
| for the directory structure. With both of these implemented, we will
| be able to do fully-online filesystem metadata validity checking
| equivalent to 'xfs_repair -n' or better.....
| 
| Reverse block mapping and directory structure parent pointers have
| been considered necessary for robust exception handling and online
| repair since we first started thinking about the CRC metadata format
| changes....

I understand now.  Thanks for the detailed explanation!


-- 
Geoffrey Wehrman  651-683-5496  gwehrman@sgi.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs