Re: truncate shows non zero data beyond the end of the inode with MAP_SHARED

[Andrea Arcangeli <andrea@novell.com>]

On Wed, Sep 15, 2004 at 02:01:06PM -0700, William Lee Irwin III wrote:
> Zeroing the final partial page during expanding truncate (flushing TLB)
> sounds like a reasonable half measure; we don't do anything at the moment.

I was only investingating solutions that would guarantee to never write
non-zero data on-disk in the last partial block of the inode, and in
turn solutions that would never trigger suprious I/O on disk.

Your suggestion is the other way around, that is we keep writing
non-zero in the half block, but exactly because of that, your "Zeroing
the final partial page", will have to mark the page dirty after that
(and probably trigger a COW if it was a MAP_PRIVATE).  Which means
_I/O_. So I think it'd be worse than my solution I suggested that
doesn't risk to write anything zero beyond the end of the file, and that
guarantees no suprious I/O will ever happen. IMHO I/O can be a lot more
costly than a double objrmap-driven pagetable walk + tlb flush.

However even doing the double pagetable walk + tlbflush around
writepages of partial pages, isn't nice at all. So I'm not sure if we've
to fix this at all.

I understood from Alan we probably shouldn't care to be posix compliant
(he nicely pointed out we're already SuSv3 compliant, which sounds good
enough) and we can keep going fast.