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.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
