1 files changed, 6 insertions, 4 deletions
diff --git a/community/gsoc/project_ideas/disk_io_performance.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn
index b6f223c8..ae634709 100644
--- a/community/gsoc/project_ideas/disk_io_performance.mdwn
+++ b/community/gsoc/project_ideas/disk_io_performance.mdwn
@@ -11,6 +11,8 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="Disk I/O Performance Tuning"]]
 
+[[!tag open_issue_hurd]]
+
 The most obvious reason for the Hurd feeling slow compared to mainstream
 systems like GNU/Linux, is a low I/O system performance, in particular very
 slow hard disk access.
@@ -18,8 +20,8 @@ slow hard disk access.
 The reason for this slowness is lack and/or bad implementation of common
 optimization techniques, like scheduling reads and writes to minimize head
 movement; effective block caching; effective reads/writes to partial blocks;
-[[reading/writing multiple blocks at once|clustered_page_faults]]; and
-[[read-ahead]].  The
+[[reading/writing multiple blocks at once|open_issues/performance/io_system/clustered_page_faults]]; and
+[[open_issues/performance/io_system/read-ahead]].  The
 [[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some
 optimizations at a higher logical level.
 
@@ -29,12 +31,12 @@ requires understanding the data flow through the various layers involved in
 disk access on the Hurd ([[filesystem|hurd/virtual_file_system]],
 [[pager|hurd/libpager]], driver), and general experience with
 optimizing complex systems.  That said, the killing feature we are definitely
-missing is the [[read-ahead]], and even a very simple implementation would bring
+missing is the [[open_issues/performance/io_system/read-ahead]], and even a very simple implementation would bring
 very big performance speedups.
 
 Here are some real testcases:
 
-  * [[binutils_ld_64ksec]];
+  * [[open_issues/performance/io_system/binutils_ld_64ksec]];
 
   * running the Git testsuite which is mostly I/O bound;