[lkml]   [1999]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Deletion of big files...
Theodore Y. Ts'o wrote:
> 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.

Except that "secure delete" should really be "secure truncate" anyway -
you don't want to abandon the bits on the disk just because someone
did a truncate(,0) just before the unlink(). So this doesn't
really help.

As for the idea of having a fast truncate for unlink() to use - that
sounds fine. However, it ideally should be used for the common case
where truncate/ftruncate/O_TRUNC is used and noone else has the file.
Can't this be done by checking the in-kernel reference count assuming
we lock the inode for the duration? Then we'd not only get the speed-up
on unlink, but also on most truncates.

Anyway, I'm no VFS whiz, so maybe I've got it all wrong. Here's a free
grain of salt to go with that message: .


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:51    [W:0.119 / U:2.704 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site