Messages in this thread | | | Date | Mon, 17 May 1999 15:38:30 -0400 (EDT) | From | "Theodore Y. Ts'o" <> | Subject | Re: Deletion of big files... |
| |
Date: Mon, 17 May 1999 03:23:56 -0400 (EDT) From: Alexander Viro <viro@math.psu.edu>
I'm not sure... Look: we spend time *not* in unlink() pre se. It's a final truncate(). And at the moment when it's called we *know* that we are sole owners of the thing and nothing else will ever try to touch it.
Careful here. One the reasons why truncate is so complicated is that we are *not* always the sole owners of the file. This comes up because truncate() isn't just called from unlink. It can also be called from ftruncate(), or from open() with O_TRUNC. A lot of the hair in truncate() is to deal with the case where another process as file descriptor open the file and is actively writing while truncate() is getting called.
The right thing to do here is to replicate the truncate function so that there's one version that's used for unlink(), where you can make all sorts of simplifying assumptions, and one version which is used in the more general case. This way, we can also get secure delete working as well. (Secure deletition was one of the casualties that got eliminated from truncate() when dealing with some of the race conditions that could happen when it was called out of ftruncate() or open(O_TRUNC).)
- Ted
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |