TR Forums

To appropriate a quote, "Unix gives you as much rope you need to hang yourself, plus a couple meters more just to be sure."

morphine wrote:

To appropriate a quote, "Unix gives you as much rope you need to hang yourself, plus a couple meters more just to be sure."

Too much rope and your feet are on the floor.

notfred wrote:

I'm guessing, but I wonder if poor power meant it couldn't up the voltage to the cores when it needed to and so the clocks didn't ramp up like they were meant to and that gave you poor latency.

Well, it wasn't that, anyway. I had no trouble overclocking my CPU and it gave the expected performance in benchmarks. Overclocked RAM too, but only a little. (2T -> 1T)

I think morphine might be on the right track tho. (*'▽')

morphine wrote:

Interesting, I wasn't fully aware of this. What if the file is multiple GBs in size? (I'm assuming the OS copies the now-deleted contents into memory?)

It's a bit more subtle. Since the directory entry (or entries, in the case of multiple hard links) for a file are stored separately from the rest of the meta-data (a.k.a. i-node), you can delete a directory entry without touching the file. The file continues to exist as it was, but only processes which had it open at the time of deletion continue to have access to it, since there's no way for other processes to find it any more.

When the last process that is referencing the deleted file closes it, the i-node is marked free, and the disk space gets reclaimed.

In the meantime, it is perfectly legal to create a new directory entry with the same name as the deleted one (and corresponding file with different content), even if some processes are still referencing the old version.

You learn something new everyday. Thanks for the info, JBI!