Linux-kernel mailing list archive 1999-20,: Re: Deletion of big files...

# Re: Deletion of big files...

Mitchell Blank Jr (mitch@execpc.com)
Tue, 18 May 1999 08:12:58 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Bernhard Rosenkraenzer: "[PATCH] CVS isdn in 2.3.x"
- Previous message: Juan Antonio Martinez: "2.2.7 NFS quota error"
- In reply to: Theodore Y. Ts'o: "Re: 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: .

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

- Next message: Bernhard Rosenkraenzer: "[PATCH] CVS isdn in 2.3.x"
- Previous message: Juan Antonio Martinez: "2.2.7 NFS quota error"
- In reply to: Theodore Y. Ts'o: "Re: Deletion of big files..."