Messages in this thread | | | Date | Fri, 24 Jan 2003 11:12:49 -0800 | From | Andrew Morton <> | Subject | Re: 2.5.59-mm5 |
| |
Alex Tomas <bzzz@tmi.comex.ru> wrote: > > >>>>> Andrew Morton (AM) writes: > > AM> That's correct. Reads are usually synchronous and writes are > AM> rarely synchronous. > > AM> The most common place where the kernel forces a user process to > AM> wait on completion of a write is actually in unlink (truncate, > AM> really). Because truncate must wait for in-progress I/O to > AM> complete before allowing the filesystem to free (and potentially > AM> reuse) the affected blocks. > > looks like I miss something here. > > why do wait for write completion in truncate?
We cannot free disk blocks until I/O against them has completed. Otherwise the block could be reused for something else, then the old IO will scribble on the new data.
What we _can_ do is to defer the waiting - only wait on the I/O when someone reuses the disk blocks. So there are actually unused blocks with I/O in flight against them.
We do that for metadata (the wait happens in unmap_underlying_metadata()) but for file data blocks there is no mechanism in place to look them up. - 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/
| |