Backgrounded deletion, dirty writeback, security, and you

[Daniel Phillips]

Hi Raymond,

On 03/23/2017 01:01 PM, Raymond Jennings wrote:
> 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?

The Tux3 backend does know how to handle outstanding dirty blocks of 
deleted files, and discards it without writing to media. For orphans, 
that is, unlinked/deleted files that are still open, dirty data in the 
most recent delta is discarded when an orphan is deleted, without being 
written to media. Your assessment of the value of this is correct, and 
you could call Tux3 intelligent in that regard.

> 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?
>
Tux3 does what you want in that case.
> 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?
>
Yes, possible, and there are good reasons for doing that as an option, 
but we do not do it at the moment. I will make sure it is on the todo list.
> My guess that if 1 was done, 2 could be done by simply fsyncing the 
> file before closing it.
You can fsync yourself if you like, or sync from the shell. The main 
reasons for zeroing out discarded data are: 1) security and 2) start 
early erase for SSD.
>
> 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.
Probably, our default will just do what you want when trim support gets 
to the top of the todo list.

Regards,

Daniel