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.
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.
Windows definitely has this "problem". I used to have %TEMP% on my SSD until I realised that VS builds were still bound by temp file + object file write bandwidth, so I've put %TEMP% onto a 1.5G ramdisk. It works very nicely.
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.
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.
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.
When creating a file handle you can usually specify how buffering will work. You can also say that everything should be written immediately. But even then there can be buffering inside the disk and cause you to lose the data. That's not the file system's fault. And sure, get rid of all those caches in between if you don't care about performance. You can do that.
And "write to the file" usually says "write to the file at a point convenient for you". Heck, it's an asynchronous call most of the time anyway so it cannot complete immediately for obvious reasons.
> But even then there can be buffering inside the disk
this, the system accounts for. If you tell the OS to sync data to disk, it has to make sure that the disk committed the data to the durable media.
One aspect of this is: As the disk, as long as it has unwritten cached data in its internal RAM cache, is free to write that data basically in any order, the OS will have to send a write barrier to the disk. Wouldn't this been accounted for by the OS, all filesystems would basically be completely broken on most power outages. Or one would have to flush the disk cache completely on every single and small change, which would severely degrade performance.
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.