in reply to Re^4: Store large hashes more efficiently
in thread 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

Replies are listed 'Best First'.
Re^6: Store large hashes more efficiently
by puterboy (Scribe) 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]
      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]
        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]

In Section Seekers of Perl Wisdom