[lkml]   [1999]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Large tmp files, async flush and still lots of I/O?
On Tue, 01 Jun 1999, you wrote:
> I am seeing large amounts of disk I/O from a program that actually writes
> and reads and afterwards deletes a temporary file. If the temporary
> file is just a few megabytes, nearly no disk I/O happens. As soon as
> the problem set gets larger to say several 30 or 50 megabytes the disk
> I/O to the temporary file starts to appear. The file itself as well as
> the program fits well into memory, I tried a machine with 512 MB RAM.
> I would believe that due to the larger size the file does stay in
> existance longer and an async write starts. But this does not appear to
> stop upon deleting the file, I get more the impression the deletion gets
> delayed as soon as the write is started. Is there some way to inhibit
> this behaviour? Preferable I would like to see no I/O at all if the file
> fits into memory.

I understand what you want. You want the temporary file to act sort of like
virtual memory. It would get swapped out to disk only if physical memory got
tight. I understand that Linux does this fairly well for files which only exist
for a few seconds. You are probably right, lazy writing kicks in and commits
the changes to disk.

Your belief that this shouldn't happen if the file has already been deleted
sounds reasonable. I think the reason it doesn't work is due to Unix unlink
semantics. To be precise, unlink() does _not_ delete a file. Rather, a file is
deleted when unlink() has been used sucessfully on all its names and all
processes have closed it. Thus, technically, in your example, the file has not
been deleted, so the kernel is right to commit it to disk. Of course, there is
probably no way to establish new links (names) for the file, so this is sort of

I don't know if this behavior should be changed or if there are more
appropriate kinds of virtual memory to use for your purpose.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:52    [W:0.038 / U:6.572 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site