aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/call-graph-from-postgresql.py
diff options
context:
space:
mode:
authorRyan Ding <[email protected]>2016-03-25 14:20:55 -0700
committerLinus Torvalds <[email protected]>2016-03-25 16:37:42 -0700
commitb46637d59f1160dee5d8e03498e667ab36c2be04 (patch)
treee01bf53fa84428fa3b86e24245e3640be5dce8ee /tools/perf/scripts/python/call-graph-from-postgresql.py
parentc1ad1e3ca3064b1f0ab5a5185b4732ab9ad8fa24 (diff)
ocfs2: use c_new to indicate newly allocated extents
To support direct io in ocfs2_write_begin_nolock & ocfs2_write_end_nolock. There is a problem in ocfs2's direct io implement: if system crashed after extents allocated, and before data return, we will get a extent with dirty data on disk. This problem violate the journal=order semantics, which means meta changes take effect after data written to disk. To resolve this issue, direct write can use the UNWRITTEN flag to describe a extent during direct data writeback. The direct write procedure should act in the following order: phase 1: alloc extent with UNWRITTEN flag phase 2: submit direct data to disk, add zero page to page cache phase 3: clear UNWRITTEN flag when data has been written to disk This patch is to change the 'c_unwritten' member of ocfs2_write_cluster_desc to 'c_clear_unwritten'. Means whether to clear the unwritten flag. It do not care if a extent is allocated or not. And use 'c_new' to specify a newly allocated extent. So the direct io procedure can use c_clear_unwritten to control the UNWRITTEN bit on extent. Signed-off-by: Ryan Ding <[email protected]> Reviewed-by: Junxiao Bi <[email protected]> Cc: Joseph Qi <[email protected]> Cc: Mark Fasheh <[email protected]> Cc: Joel Becker <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/call-graph-from-postgresql.py')
0 files changed, 0 insertions, 0 deletions