"secure" file flag?

[Wes Peters]

On Friday 21 November 2003 03:56 pm, Stefan Eßer wrote:
> On 2003-11-21 14:09 -0800, Wes Peters <wes at softweyr.com> wrote:
> > As for performance, you really need to flush the on-device cache on
> > each pass to make sure the bit patterns get written to the platter in
> > proper order.  I don't see any clever way to coalesce the writing of
> > the various patterns to multiple blocks short of a kernel thread,
> > either, so performance would be abysmal.  Imagine removing a large
> > file, overwriting each block in 37 (IIRC) passes, syncing all the way
> > through the on-disk cache after *every block.*
>
> I may be way off, but I do not think, that a special thread or
> a cache flush after each block is required:
>
> A simple algorithm could just mark each buffer with a special
> kind of dirty flag and a counter for the pass number (in fact,
> the existing dirty flag could be used, and a counter set to the
> number of passes required, with 0 indicating that the buffer is
> to be flushed to disk "as is" in the normal way).

Oh, but you're wrong, if you actually want to ERASE the data on the disk 
platters.  That's why I've referred people to the obliterate program in 
ports several times.  Read the references contained there, then come back 
to this discussion.

If you just want to zero the blocks, that is a lot easier, but you're not 
really protecting anything from anyone who can get their hands on the 
disk.

-- 

        Where am I, and what am I doing in this handbasket?

Wes Peters                                               wes at softweyr.com