On Fri, Oct 11, 2013 at 12:42 PM, David Sterba <dsterba@xxxxxxx> wrote: > On Sun, Oct 06, 2013 at 10:22:33PM +0100, Filipe David Borba Manana wrote: >> 2) On 32 bits machines. Th VFS hash values are unsigned longs, which >> are 32 bits wide on 32 bits machines, and the inode (objectid) >> numbers are 64 bits unsigned integers. We simply cast the inode >> numbers to hash values, which means that for all inodes with the >> same 32 bits lower half, the same hash bucket is used for all of >> them. For example, all inodes with a number (objectid) between >> 0x0000_0000_ffff_ffff and 0xffff_ffff_ffff_ffff will end up in >> the same hash table bucket. > > Well, inode number that does not fit into 32 bits on a 32 bit machine > causes other problems. And subvolume ids that do not fit into 32 bits > cannot be stored in radix tree. > > It would be safer to refuse creating/accessing inode/subvolume with > nubmer that does not fit into 32bits. Good point David. However it would be a rather radical behaviour change imho. I think it should be a separate change if there are no objections against such change. > > david -- Filipe David Manana, "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men." -- 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
