4 ms·

Why does Microsoft still store temporary files on disk? (as opposed to a RAM-backed temporary file system as used in most other operating systems) Is there a r

by sspiff 12y ago

Why does Microsoft still store temporary files on disk? (as opposed to a RAM-backed temporary file system as used in most other operating systems) Is there a reason for this? It just seems like it would cause clutter and garbage to pile up for eternity.

B-Con 12y ago
If for no other reason: We would probably be surprised and saddened to see how much software abuses the longevity of "temporary" files and being able to persist them across reboots.
- CJefferson 12y ago
  I get annoyed for the opposite reason -- I wish it was easier to say to the OS "Take this directory away when this program finishes". You can get so far with atexit, or unlinking early (but that's no good if you want to pass the files on to other programs).
icebraining 12y ago
Ubuntu doesn't use tmpfs for /tmp either. The reason is simple: some applications write huge temporary files, and lots of people don't have much free memory to spare. And you can solve the pileup by simply cleaning it up regularly using a scheduled task.
- contingencies 12y ago
  This is why we need better application profiling yesterday. Not "I need write to x location" but "I am highly sensitive to read latency in x location, and highly sensitive to available space (append only) in y location." cgroups is the beginning. Eventually, a much-evolved container notion will solve this. I expect embedded and mobile distributions/OSs to follow suit.
  - raverbashing 12y ago
    It's good until someone abuses this
rwmj 12y ago
Because using a RAM-backed temporary fs is a dumb idea. If your disk caching is implemented properly, then most temporary files are stored in RAM, but larger ones can be spilled to disk, and the OS gets to decide what's best based on a global view of the system. By using a RAM-backed tmpfs you are forced to use RAM and spill to a swap partition that is inflexible and hard/impossible to resize.
- icebraining 12y ago
  Well, it's not only larger files that spill to disk; using a normal directory forces the OS to write them all to disk (even if with a delay thanks to buffers). A RAM-backed tmpfs, on the other hand, would avoid writing to disk if the size of your files doesn't cross the threshold of free memory.
  - rwmj 12y ago
    This is incorrect. Linux doesn't write small files to disk if they are deleted within a certain time. And if that's true for Windows NT, then it's a problem with Windows.
    - hueving 12y ago
      Seriously? So if you write a key file or something small to disk and immediately pull the plug on your computer, it will be gone? That is incredibly stupid for a file system that people expect to actually write the file when it says it did.
      - icebraining 12y ago
        Yes, seriously, unless the software calls fsync(). As a user, you can avoid that by mounting your disks with the 'sync' option, but prepare for your system to become very slow.
      - rwmj 12y ago
        As the reply from icebraining says, if your program doesn't call fsync(2) or fdatasync(2) but still expects the file to be on disk when someone pulls the plug, then your program has a bug, not the OS.

by sspiff 12y ago

B-Con 12y ago

If for no other reason: We would probably be surprised and saddened to see how much software abuses the longevity of "temporary" files and being able to persist them across reboots.

CJefferson 12y ago
I get annoyed for the opposite reason -- I wish it was easier to say to the OS "Take this directory away when this program finishes". You can get so far with atexit, or unlinking early (but that's no good if you want to pass the files on to other programs).

icebraining 12y ago

Ubuntu doesn't use tmpfs for /tmp either. The reason is simple: some applications write huge temporary files, and lots of people don't have much free memory to spare. And you can solve the pileup by simply cleaning it up regularly using a scheduled task.

contingencies 12y ago
This is why we need better application profiling yesterday. Not "I need write to x location" but "I am highly sensitive to read latency in x location, and highly sensitive to available space (append only) in y location." cgroups is the beginning. Eventually, a much-evolved container notion will solve this. I expect embedded and mobile distributions/OSs to follow suit.
- raverbashing 12y ago
  It's good until someone abuses this

rwmj 12y ago

Because using a RAM-backed temporary fs is a dumb idea. If your disk caching is implemented properly, then most temporary files are stored in RAM, but larger ones can be spilled to disk, and the OS gets to decide what's best based on a global view of the system. By using a RAM-backed tmpfs you are forced to use RAM and spill to a swap partition that is inflexible and hard/impossible to resize.

icebraining 12y ago
Well, it's not only larger files that spill to disk; using a normal directory forces the OS to write them all to disk (even if with a delay thanks to buffers). A RAM-backed tmpfs, on the other hand, would avoid writing to disk if the size of your files doesn't cross the threshold of free memory.
- rwmj 12y ago
  This is incorrect. Linux doesn't write small files to disk if they are deleted within a certain time. And if that's true for Windows NT, then it's a problem with Windows.
  - hueving 12y ago
    Seriously? So if you write a key file or something small to disk and immediately pull the plug on your computer, it will be gone? That is incredibly stupid for a file system that people expect to actually write the file when it says it did.
    - icebraining 12y ago
      Yes, seriously, unless the software calls fsync(). As a user, you can avoid that by mounting your disks with the 'sync' option, but prepare for your system to become very slow.
    - rwmj 12y ago
      As the reply from icebraining says, if your program doesn't call fsync(2) or fdatasync(2) but still expects the file to be on disk when someone pulls the plug, then your program has a bug, not the OS.