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: .
-Mitch
-
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/