Messages in this thread | | | Date | Wed, 15 Sep 2004 23:58:10 +0200 | From | Andrea Arcangeli <> | Subject | Re: truncate shows non zero data beyond the end of the inode with MAP_SHARED |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |