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

-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/