Re: [PATCH, RFC] fix null files exposure growing via ftruncate

[Christoph Hellwig <hch@infradead.org>]

On Thu, Jun 14, 2007 at 04:34:04PM +1000, David Chinner wrote:
> Christoph,
> 
> Looking into the test 140 failure you reported, I realised that none
> of the specific null files tests were being run automatically, which
> is why I hadn't seen any of those failures (nor had the QA team).
> That's being fixed.
> 
> I suspect that the test passes on Irix because of a coincidence
> (the test sleeps for 10s and that is the default writeback
> timeout for file data) which means when the filesystem is shut down
> all the data is already on disk so it's not really testing
> the NULL files fix.
> 
> The failure is due to the ftruncate() logging the new file size
> before any data that had previously been written had hit the
> disk. IOWs, it violates the data write/inode size update rule
> that fixes the null files problem.
> 
> The fix here checks when growing the file as to whether it the disk
> inode size is different to the in memory size. If they are
> different, we have data that needs to be written to disk beyond the
> existing on disk EOF. Hence to maintain ordering we need to flush
> this data out before we log the changed file size.
> 
> I suspect the flush could be done more optimally - I've just done a
> brute-force flush the entire file mod. Should we only flush from the
> old di_size to the current i_size?
> 
> There may also be better ways to fix this. Any thoughts on
> that?

Looks good enough for now, but I suspect just flushing from the old
to the new size would be a quite nice performance improvement that's
worth it.