On Thu, 3 Feb 2011, Chris Dunlop wrote: > On 2011-02-03, Sage Weil <sage@xxxxxxxxxxxx> wrote: > > There are a couple of levels of difficulty. The main problem is that the > > only truly stable information in the NFS fh is the inode number, and > > Ceph's architecture simply doesn't support lookup-by-ino. (It uses an > > extra table to support it for hard-linked files, under the assumption that > > these are relatively rare in the real world.) > > Sorry for the thread hijack, but just so this issue doesn't completely > fall through the cracks... > > There are different "real worlds" where hard links are very, very > common. Although, admittedly, ceph may well not be targeted at those > parallel universes. > > Backup servers are a classic example. It's very common to have > hard-links between the files for each snapshot. In this situation *most* > files have multiple hard links, and you can easily have almost all files > with 60 or more hard links (for 60 or more snapshots). Rsnapshot, > BackupPC and apparently OSX's Time Machine for instance work this way. Yep. These apps will work.. mostly. The current pain point will be the anchor table, which isn't built to scale currently (it's pretty trivial, everything in memory). Assuming that is addressed, though, these workloads won't be too bad. The nice thing is that these links are usually "parallel" in that all the dentries in one dir are hard linked to the same targets in another dir. Although the MDS pays a cost looking up the anchor for the first name, the result is that it loads the second directory into cache, and the subsequent links are also resolve for "free." The result is a lookup cost that is more like O(number of dirs) instead of O(number of files). sage -- 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
