On 12/14/2010 09:37 PM, Lennart Poettering wrote: > On Sun, 12.12.10 19:49, John Reiser (jreiser@xxxxxxxxxxxx) wrote: > >> The project is a database system that creates and dlopen()s >> plugins on-the-fly, for better performance on ["long-running"] queries. >> We like the speed of creat+write+close+open+read+mmap on /dev/shm. >> If /dev/shm and /tmp both become off limits, then what is >> the recommended replacement location? > > The API for /dev/shm is shm_open(). Unless you are using that API you > shouldn't really touch /dev/shm. > > What's wrong with /tmp for your use cases? As I wrote another place under this topic (at http://lists.fedoraproject.org/pipermail/devel/2010-December/147159.html which crossed in the posting mail), some applications prefer to avoid /tmp for such purposes because /tmp often is too slow: a real harddrive (needs capacity larger than RAM) with a heavy-weight file system (to provide full-featured ACLs, etc.) which often suffers contention. Also, the claim "The API for /dev/shm is shm_open()" is incorrect. See the other message for the history. When something is in the file system, then by default the file system APIs (including creat, open, read, write, close, execve, dlopen, ...) are legitimate uses. (Originally [System V] shared memory was *not* in the file system, and this caused problems.) -- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
