Re: 2.5.59-mm5

Andrew Morton
2003-01-24T19:12:25Z

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.