Модуль ядра Linux для самооптимизирующихся жестких дисков: совет?

Question

Я студент компьютерного факультета, изучаю разработку ядра Linux.Моей команде из 4 человек было поручено предложить проект разработки ядра (который будет реализован через 6 недель), и мы разработали предварительный «Самооптимизирующийся модуль ядра Linux на жестком диске».Я не уверен, имеет ли это название смысл для профессионалов.

Мы основали предложение на этом проекте .

Цель проекта - минимизировать объем жесткого диска.время доступа.План состоит в том, чтобы создать специальный раздел, в который должны быть помещены «наиболее часто используемые» файлы.LKM будет профилировать, анализировать, планировать и перенаправлять операции ввода-вывода на жесткий диск.Этот LKM должен в первую очередь иметь возможность прогнозировать и перенаправлять весь доступ к файлам (для файлов размером менее 10 МБ) с минимальными издержками и уменьшать среднее время доступа для чтения / записи к жесткому диску.Я считаю, что Apple HFS имеет эту функцию.

Кто-нибудь может предложить отправную точку?Недавно я нашел способ перенаправить операции ввода / вывода, перехватывая системные вызовы ( угон всех операций чтения / записи).Однако я не уверен, что это лучший путь.Есть ли способ написать драйвер, который перенаправляет эти операции чтения / записи?Можем ли мы воспользоваться кешем чтения / записи для достижения того же эффекта?

Любая обратная связь приветствуется.

Answer 1

Возможно, вы захотите взглянуть на Unionfs.Вам даже не нужен LKM - просто какой-то демон пользовательского пространства, который будет подписываться на события inotify, вести статистику и переносить файлы между разделами.Unionfs объединит оба раздела в одну логическую файловую систему.

Answer 2

Есть много способов, которыми такая оптимизация может быть полезна:

• доступ к файлу A подразумевает, что файл B доступ неизбежен.Пример: открытие файла значков для мультимедийного файла медиаплеером
• , доступ к любому файлу в некоторой группе G файлов означает, что к другим файлам в группе будет доступ в ближайшее время.Пример: mysql получает команду use somedb, которая подразумевает доступ ко всем таблицам файлов, индексам и т. Д.
• программа, которая прекращает чтение последовательного файла, предполагает, что программа остановлена ​​или завершена, поэтому прогнозыот будущих обращений, связанных с этим файлом, следует отказаться.
• с несколькими (но прозрачными) копиями некоторых часто упоминаемых файлов, стратегически разбросанных по всему, можно использовать копию, ближайшую к головкам дисков.Пример: некэшированные каталоги или небольшие, часто используемые файлы настроек.

Существует так много возможностей, что я думаю, что по крайней мере 50% эффективного решения будет разумной, ограниченной спецификацией для функций, которые вы будете использоватьреализовать и что вы не будете.Было бы полезно изучить, как агрессивный механизм кэширования файлов в Microsoft Vista разочарован .

Другая проблема, с которой вы можете столкнуться в современном дистрибутиве Linux, заключается в том, насколько хорошо система уже выполняет большую часть того, что вы планируетеулучшить.На самом деле, измерение улучшения может быть большой проблемой.Я предлагаю написать эталонную программу, которая открывает и читает серию файлов и точно определяет время полной последовательности.Запустите его несколько раз с включенными и отключенными улучшениями.Но вам придется перезагрузиться между ними для правильного времени ....