<div dir="ltr"><div><div><div><div><div><div><div><div>Having recently tangled with this issue on ext4, I had a few questions:<br><br></div>1.  Does the backend that actually digests an unlink request know how to handle outstanding dirty blocks belonging to a now nonexisting file?<br><br></div>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.<br><br></div>Is tux3 intelligent enough to seek out and void any writeback against unlinked files and spare the disk from ostensibly moot writeback?<br><br></div>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?<br><br></div>2.  Exception to point 1, erasing a file<br><br></div>Is it possible for tux3 to explicitly zero out a file's data before releasing its blocks back to the free pool?<br><br></div>My guess that if 1 was done, 2 could be done by simply fsyncing the file before closing it.<br><br></div>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.<br><br></div>