Backgrounded deletion, dirty writeback, security, and you

[Raymond Jennings]

Having recently tangled with this issue on ext4, I had a few questions:

1.  Does the backend that actually digests an unlink request know how to
handle outstanding dirty blocks belonging to a now nonexisting file?

If a file has been deleted, has no outstanding descriptors referencing it,
then in theory none of the data in it will be useful anymore.  That
probably includes any dirty data in page cache or whatever that was due to
be written back to the disk.

Is tux3 intelligent enough to seek out and void any writeback against
unlinked files and spare the disk from ostensibly moot writeback?

Usage case:  I have a process that went haywire and wrote a crapton of
data...and then it crashed and made the entire output useless.  If I delete
it, will tux3 notice and promptly discard any pending writeback against the
file, since I'd rather the system just forget about flushing it after the
file has been deleted?

2.  Exception to point 1, erasing a file

Is it possible for tux3 to explicitly zero out a file's data before
releasing its blocks back to the free pool?

My guess that if 1 was done, 2 could be done by simply fsyncing the file
before closing it.

And maybe it would be a good feature if tux3 could be instructed to zero
out blocks before they're released, perhaps as amount time default option,
or perhaps explicitly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://phunq.net/pipermail/tux3/attachments/20170323/5351924e/attachment.html>