gsoc/project_ideas: Restore all project ideas here

While there is certainly some overlap with other areas, it is *not*
acceptable to drop mentors and exercises from GSoC tasks, nor to add
random crap, nor do any other changes that make them less useful as GSoC
tasks -- and this is *not* obvious if they do not live in the
project_ideas namespace. It's also confusing in general.

I tried to preserve all valid changes to the task descriptions themself
-- though I might have messed up some things.

I did leave the now redundant entries in open_tasks in place. Not sure
how to deal with them. As the content is virtually identical anyways,
they probably should be just turned into stubs pointing here. Or don't
list them explicitely at all -- we point out in other places that GSoC
ideas are useful in other contexts too...

For the future, please refrain from reorganising things here without
prior discussion.

1 files changed, 48 insertions, 0 deletions

diff --git a/community/gsoc/project_ideas/disk_io_performance.mdwn b/community/gsoc/project_ideas/disk_io_performance.mdwn
new file mode 100644
index 00000000..b6f223c8
--- /dev/null
+++ b/community/gsoc/project_ideas/disk_io_performance.mdwn
@@ -0,0 +1,48 @@
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="Disk I/O Performance Tuning"]]
+
+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.
+
+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
+[[ext2_filesystem_server|hurd/translator/ext2fs]] might also need some
+optimizations at a higher logical level.
+
+The goal of this project is to analyze the current situation, and implement/fix
+various optimizations, to achieve significantly better disk performance. It
+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
+very big performance speedups.
+
+Here are some real testcases:
+
+  * [[binutils_ld_64ksec]];
+
+  * running the Git testsuite which is mostly I/O bound;
+
+  * use [[TopGit]] on a non-toy repository.
+
+
+Possible mentors: Samuel Thibault (youpi)
+
+Exercise: Look through all the code involved in disk I/O, and try something
+easy to improve. It's quite likely though that you will find nothing obvious --
+in this case, please contact us about a different exercise task.