Я проходил через файловую систему Google (GFS), он упоминает, что GFS использует выделение пространства Lazy для уменьшения внутренней фрагментации.
Может ли кто-нибудь объяснить, как ленивое пространство уменьшает внутреннюю оцепенение?
Источник: http://research.google.com/archive/gfs-sosp2003.pdf
При ленивом распределении пространства физическое распределение пространства задерживается как можно дольше, пока не будет накоплено данных размером размера блока (в случае GFS, 64 МБ в соответствии с документом 2003 года). Другими словами, процесс принятия решения, предшествующий распределению нового фрагмента на диске, сильно зависит от размера данных, которые должны быть записаны. Это предпочтение ожидания вместо выделения большего количества фрагментов, основанных на какой-либо другой характеристике, сводит к минимуму вероятность внутренней фрагментации (т.е. Неиспользуемые части фрагмента 64 МБ).
В документе Google также говорится: "Большинство фрагментов заполнено, потому что большинство файлов содержат много фрагментов, только последний из них может быть частично заполнен". Таким образом, такой же подход применяется к созданию файла.
Это аналогично: http://duartes.org/gustavo/blog/post/how-the-kernel-manages-your-memory
Я не прочитал всю статью... но я надеюсь, что следующий фрагмент поможет вам в малой степени.
Первый вопрос, который я задал бы, заключается в следующем: каков эффект наличия больших размеров блоков в файловой системе? Скажем, размер блока FS составляет 64 МБ. Хорошая новость заключается в том, что мы пишем в хороших смежных кусках на жесткие диски (больше данных за каждый поиск), меньше метаданных, чтобы держать в непрямых блоках и т.д. Плохая новость - это внутренняя фрагментация.. если файл равен 1 МБ, но минимальный размер блока - 64 МБ, существует внутренняя фрагментация 63 МБ. Итак, как получить хорошие новости и избежать плохих новостей?
Один из способов - сделать ленивое выделение пространства или отложить выделение пространства. Здесь мы сохраняем размер блока небольшим (например, 1 МБ), но мы пишем большой кусок данных, то есть много блоков 1 МБ вместе, когда мы пишем на диск. Таким образом, мы получаем доброту больших блоков записи. Обратите внимание, что это означает, что мы пишем в буфере инсталляции, но передаем вызов write() sys, что он записывается на диск... точно так же, как запись в буферный кеш.
ПРИМЕЧАНИЕ. Когда "время" пришло, чтобы выполнить реальное выделение блоков, нам нужно быть гарантированным местом на диске. Таким образом, отложенное выделение блока = > резервирование пространства выполняется во время записи, но выделение пространства выполняется позднее, когда количество блоков данных накапливается в ядре.
Данные сначала записываются в буфер. Таким образом, вместо того, чтобы выделять память в момент создания файла, они ожидают, пока не произойдет фактическая запись. Как и в XFS http://en.wikipedia.org/wiki/XFS#Delayed_allocation
Вам не нужно фиксировать размер файла при создании. И вы можете добавить его в больший файл. Вы можете ссылаться на .