[GRASS-dev] Re: what if: a new GRASS directory layout?

[Glynn Clements]

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 <glynn at gclements.plus.com>