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? [sorry to be late for this thread, I understand the original message should be treated as a bug of systemd not reapplying stuff from fstab after it was done with its own internal needs] I would like to bring to the attention of the list another current usage of the tmpfs mounted on /dev/shm in Fedora packages: Jack (the Jack Audio Connection Kit, jackaudio.org) has been using the file api (apologies if my wording is not absolutely correct in unix terms) on the tmpfs filesystem that is mounted on /dev/shm for a very long time (10 years?). "/tmp" is not useful to Jack because Jack's internal communication pipes can't be stored in any disk based journaled filesystem as the latencies involved in accessing them cause glitches in the audio streams handled by Jack. I raise this issue because "The API for /dev/shm is shm_open()" statement above means to me that in the future there will be no file api access to a ram mounted filesystem in Fedora (I understand that this is my own conclusion, but I can't see any other given the wording of the statement above). Before someone implements that idea, please consider the needs of a filesystem in ram for such uses as those mentioned in this thread (and that is supported by the Fedora distribution by default). Just in case... -- Fernando -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
