[Top] [All Lists]

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

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [RFC 00/17] RFC parent inode pointers.
From: Geoffrey Wehrman <gwehrman@xxxxxxx>
Date: Tue, 28 Jan 2014 16:02:30 -0600
Cc: Mark Tinguely <tinguely@xxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20140128030040.GG2212@dastard>
References: <20140115220012.624438534@xxxxxxx> <20140116055607.GR3431@dastard> <52D99FD2.6000601@xxxxxxx> <20140118031247.GE18112@dastard> <52E6B67B.6070001@xxxxxxx> <20140128030040.GG2212@dastard>
User-agent: Mutt/1.5.14 (2007-02-12)
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?

Geoffrey Wehrman

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