On Wed, 15.12.10 08:44, John Reiser (jreiser@xxxxxxxxxxxx) wrote: > > I don't think there's a particularly good reason to use that filesystem for > > other uses. Just mount another tmpfs elsewhere. > > mount() requires CAP_SYS_ADMIN and therefore an application cannot rely > on performing mounts. A major point of this thread is that an application > wants to rely on using a file system that is present on all boxes, can be > accessed without special permissions or capabilities, and offers very > fast performance for small numbers of small-to-medium-sized files. > /dev/shm was the best choice until systemd in Fedora 15 rawhide mounted > /dev/shm with MS_NOEXEC. Even the preview edition of Ubuntu 11.04 > omits the MS_NOEXEC. The appropriate place for this is /tmp. /dev/shm always has been an implementation detail of shm_open(), and accessing it directly makes only sense for admins and low-level system tools that are used to manage shared memory areas. But it is not a generic place to dump arbitrary stuff. The FHS does not offer file systems for all thinkable uses. However, most distributions have subsequently updated its semantics, and depending on your application you might find a more suitable place to place your files. For example, /var/run sounds like it is something you might want to use (if your code is privileged at least), and on more recent distros (including F15) it is actually a tmpfs. Its purpose is that it is used for small files, sockets, fifos that are used for communication between processes and life-cycle management. Newer versions of the XDG basedir spec also specify $XDG_RUNTIME_DIR which offers similar semantics for unprivileged code and whose lifetime is strictly bound to the user being logged in. This is first properly implemented in systemd, and hence will be available properly in F15, too. It too is tmpfs (since it is actually located beneath /var/run). So, in summary: there are places which might be more appropriate for your small files, but /dev/shm is not a good place for it, and never has been. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
