My understanding is that the limit on the number of hardlinks to the same file stored in the same directory, is, because the names of the hardlinks are stored within the same inode. As such the number of hardlinks is naturally limited by the size of the inode (and dependent on the length of the filenames). Correct?
Correct enough :). Yes, there is a limited amount of space associated with an inode that tracks hard links and the name of the link consumes that space. The details are a little different. The backrefs to a given inode are stored in one item in the tree whose size is limited by the block size of the leaves in the tree.
It's not a big deal, but with my original posting I just tried to point out that btrfs fails an operation while the above constraint is not violated. The size needed to store the filename "a" is exactly the same as the size needed to store the filename "b". Therefore, I would assume the operation mv "a" "b" to just work.
Huh, indeed. I'd hope that the current behaviour could be fixed. In flipping through the code it certainly looks like it adds the new backref for the new name before it unlinks the old name and removes the old backref. - z -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
