dect
/
linux-2.6
Archived
13
0
Fork 0
Code Releases Activity

[XFS] Explain the race closed by the addition of vn_iowait() to the start 

of xfs_itruncate_start().

SGI-PV: 947420
SGI-Modid: xfs-linux-melb:xfs-kern:25527a

Signed-off-by: David Chinner <dgc@sgi.com>
Signed-off-by: Nathan Scott <nathans@sgi.com>
This commit is contained in:
David Chinner 2006-03-22 12:47:15 +11:00 committed by Nathan Scott
parent 9fa8046f50
commit 38e2299a64
1 changed files with 10 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
fs/xfs/xfs_inode.c
View File

@ -1393,6 +1393,16 @@ xfs_itrunc_trace(
* calling into the buffer/page cache code and we can't hold the
* inode lock when we do so.
*
* We need to wait for any direct I/Os in flight to complete before we
* proceed with the truncate. This is needed to prevent the extents
* being read or written by the direct I/Os from being removed while the
* I/O is in flight as there is no other method of synchronising
* direct I/O with the truncate operation. Also, because we hold
* the IOLOCK in exclusive mode, we prevent new direct I/Os from being
* started until the truncate completes and drops the lock. Essentially,
* the vn_iowait() call forms an I/O barrier that provides strict ordering
* between direct I/Os and the truncate operation.
*
* The flags parameter can have either the value XFS_ITRUNC_DEFINITE
* or XFS_ITRUNC_MAYBE. The XFS_ITRUNC_MAYBE value should be used
* in the case that the caller is locking things out of order and