Re^5: Store large hashes more efficiently

How are the integers related to the hex strings?

(I have a method that can reduce the storage requirement to ~250MB; but I'm not sure it will work for your purpose?)

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^5: Store large hashes more efficiently
Re^6: Store large hashes more efficiently by puterboy (Beadle) on Feb 12, 2013 at 16:26 UTC
Integers are inodes. Hex strings correspond to an md5-like hash of the file stored in the inode.	[reply]
Re^7: Store large hashes more efficiently by BrowserUk (Pope) on Feb 12, 2013 at 16:38 UTC
Integers are inodes. Hm. Looking around the web, it seems that inode numbers are of type `ino_t`; which seems to be typedef'd as unsigned long. Do you really need Q? With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l]
Re^8: Store large hashes more efficiently by puterboy (Beadle) on Feb 13, 2013 at 01:56 UTC
I don't today... but I am writing this software as a utility for an open software project where people may have much larger filesystems. Since one can have 1 inode per 4K block, I was assuming that one might need to go beyond longs when drives/filesystems hit 16TB... but if inodes are type long, then I imagine that mkfs.ext4 (and its ilk) will just enforce a larger minimum bytes-per-inode size. Anyway, good to know that I can for now get by with using 'V' and not 'Q'. Thanks!	[reply]