Ivan Shmakov wrote: > > In-process references could be maintained by making a copy (or hard > > link) to the inventory, so that the GC treats it as "live". You would > > need some kind of clean-up mechanism to handle any copies which are > > left behind if a module crashes. > > However, having GC to process all the inventories won't be > efficient (unless these are stored in a database's table with > appropriate indices.) So, I had in mind keeping a references > file along with each object file.
Ah; if you're talking about back-references, one thing to bear in mind is permissions: you can use maps from mapsets for which you only have read permission, and not write permission. [This issue has already arisen with respect to reclass maps and the reclassed_to file. That was the first GRASS bug I ever fixed.] That also means that garbage collection would need to scan the entire location, not just individual mapsets. Actually, re-projection can span locations, so you would potentially need to scan the entire database. > > [BTW, it has been pointed out that this can reduce the maximum number > > of maps per mapset, as the limit on an inode's hard link count limits > > the maximum number of subdirectories, while there is usually no fixed > > limit on the number of files. E.g. on Linux' ext2fs, the maximum hard > > link count is 65535, so you can't have more than 65533 subdirectories.] > > While the inventory scheme is free from hitting this limit. OTOH, if you don't use subdirectories, you will have many more files in a single directory. This can be a major performance issue on some filesystems. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
