[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.027 / U:52.824 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site