Re: parent xattrs on file objects

["Adam C. Emerson" <aemerson@linuxbox.com>]

Mr. Farnum,

At Wed, 17 Oct 2012 15:04:23 -0700, Gregory Farnum wrote:
> 
> I still don't get it. Putting every inode's primary link in a lookup
> directory and then patching the lookup code to go there makes sense to
> me. But if you have to go the other way (from the inode directory's
> secondary link to some other location as the primary link), you need
> an up-to-date path for that primary link, right? How do you handle it
> when the path changes — do you have a two-phase commit on the lookup
> directory attributes?

Our idea isn't to have the inode directory contain links back to the
primary.  Our idea is to have a structure managed by MDSs that is
looked up by inode number and spread across the MDSs in a cluster
similarly to the way CRUSH maps files across OSDs.  This structure
contains all the information currently in the inode that's now
incorporated into the dirent.

The dirents would then contain mappings from mappings from names to
inodes and possibly cache (but not be the primary for) inode content.
We were also planning to change directory fragmentation to distribute
fragments across MDSs based on a function of the filename, also
similarly to how CRUSH maps objects to OSDs.

Respectfully yours,

Adam C. Emerson                                  <aemerson@linuxbox.com>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html