lkml.org 
[lkml]   [2003]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.065 / U:5.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site