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@xxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
