Operation system (OS) knows about current i/o file operation (like start of file operation (creating, copying, renaming and others), end of file operation). Why not have a separate database (like mlocate.db) for file (directory) structure, records which would reflect fully current file (directory) structure and updates at every file operation? This update could be realized in function called by the signal of OS at i/o operation. As a result we'll have all "beauties" of database using:
1) Very quick file search (by size, name etc., include regexp).
2) Very quick showing directories size.
3) Increasing file system (fs) reliability due to the actual duplication of it's structure.
4) Using various sums (like crc, md5, sha, ...), stored as a separate field of file properties in database.
5) Possibility of quick coping and backuping of all file (directory) structure.
6) No need to periodically directory scan (like it do mlocatedb).
7) And many many others benefits...
Using of this approach DON'T INCREASE processor loading. This "paralleling" of fs structure could be realized for existing fs.
By the author opinion, fs structure "paralleling" in separate database must be a standard for new versions of fs ("DB Linked FS").