Alex Tomas [off-list ref] wrote:

quoted

quoted

quoted

quoted

quoted

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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/