0

Are temporary files created with mkstemp synced to disk?

Here is what I have:

  1. Program creates temporary file using mkstemp and sends fd to another program.

  2. This temporary file is mmap-ped by both programs and used heavily (up to 400 MB/sec of writes and 400 MB/sec of reads; up to 60 reads and writes per second).

  3. I can't use memfd_create (may not be supported on target devices).

  4. Lets also assume (and this is almost true) that I can't create this file on tmpfs (like in /tmp).

What I need is guarantee that such file will not stress hard disk. I can't allow it to be written to disk even if this only happens once every 5 seconds. If I can't get such guarantee, I will look for another way.

Additional info (not important):

I am writing wayland compositor for Android devices. Currently temporary files (wayland surfaces actually) are created on tmpfs. And everything works fine as long as SELinux is not enabled. But if I enable SELinux, it prevents fd's from being transferred from client to compositor. Only solution I currently know is to create temporary files in app's home dir. But if such way is dangerous, I will find another.

Sion0
  • 77
  • 7
  • 2
    By "sends the fd to another program" do you means sends the *file name* to another program? Or perhaps *forks* another program that inherits the fd? Because the meaning of an fd is not in the number itself, and handing it off to an unrelated other program does not provide a means for the receiving program to access the same file. – John Bollinger Jul 11 '19 at 19:00
  • 2
    fd is transferred via unix domain socket. In this case, another program can use the same file. – Sion0 Jul 11 '19 at 19:22
  • 2
    Why not use shared memory? – stark Jul 11 '19 at 19:29
  • sysv shm? It is deprecated. Also my program is wayland compositor for android. I can't change all wayland clients to use shm. They send fd. – Sion0 Jul 11 '19 at 19:42
  • 1
    *POSIX* shm. Which works in terms of file descriptors and `mmap()`. – John Bollinger Jul 11 '19 at 19:44
  • Thanks, I'll check what it is. But this may only work if no real files are created. If shm_open() creates file under /dev/shm or anywhere, using this shm api will not solve anything. – Sion0 Jul 11 '19 at 19:48
  • Oh, wait. I CAN'T change how wayland clients get fd... I can with LD_PRELOAD maybe... But this is not desirable. – Sion0 Jul 11 '19 at 19:51
  • So it is the *client* that creates the file? – John Bollinger Jul 11 '19 at 19:53
  • Yes... Wayland clients create temporary file using mkstemp and send fd to server. All I can change is PATH to directory where temporary files are created (using env variable which is respected by clients). But if I set this path to tmpfs, SELinux prevents fd from being transferred. Again, compositor already works fine if SELinux is not enabled. Also, on android devices its very hard to add new SELinux rules... – Sion0 Jul 11 '19 at 19:59
  • If creating temporary file using mkstemp in persistent memory is (or may be) dangerous, I'll try to mess with SELinux... – Sion0 Jul 11 '19 at 20:06

1 Answers1

1

Are temporary files created with mkstemp synced to disk?

The mkstemp function does not impart any special properties to files it opens that would prevent them from being synced to disk. The filesystem on which they are created might have such a property, but that's independent of file creation. In particular, files created via mkstemp() will persist indefinitely if not removed.

What I need is guarantee that such file will not stress hard disk. I can't allow it to be written to disk even if this only happens once every 5 seconds. If I can't get such guarantee, I will look for another way.

As far as I am aware, even tmpfs filesystems do not guarantee that their contents will remain locked in memory, as opposed to being paged out. They are backed by virtual memory. But if the actual file is comparatively small and all its pages are hot, then they are likely to remain in memory only.

With regard to the larger problem,

everything works fine as long as SELinux is not enabled. But if I enable SELinux, it prevents fd's from being transferred from client to compositor. Only solution I currently know is to create temporary files in app's home dir.

By default, newly-created files inherit the SELinux type of their parent directory. Your Wayland clients presumably do not have sufficient privilege to modify the SELinux labels of the files they create, but you should be able to administratively create a directory wherever you like with a label conducive to your needs. For example, you could cause a subdirectory of /dev/shm to be created for the purpose (at every boot), and chconned to have an appropriate label. If the clients create their temp files there then they should inherit the SELinux type you choose.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • Oki, thanks. I also found this: https://stackoverflow.com/questions/3146496/how-to-have-a-checkpoint-file-using-mmap-which-is-only-synced-to-disk-manually So it seems there is no way to ensure data is not synced. Going to experiment with SELinux. On android devices managing SELinux is harder, but chcon is available (at least for rooted devices). Thanks for tips. – Sion0 Jul 11 '19 at 20:37
  • 1
    Yay, it works. I took context from my apk's home dir and chconned other dir (on tmpfs) to have same context. Now clients are able to create temporary files in this dir and SELinux doesn't prevent fd's from being transferred to server. Sorry for offtopic. – Sion0 Jul 11 '19 at 20:51