The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..."
Отправлено iZEN, 25-Авг-12 13:26 
> Я проморгал про удаление, и писал про то, что на CoW мы
> получим лапшу по всему диску хоть с преаллокацией, хоть без оной.

А на обычных не-CoW ФС с преаллокацией не будет "лапши"? Вообще же, разработка грамотной преаллокация довольно трудоёмка для любых современных ФС, так как ФС научились учитывать размещение групп одинаковых байтов (того, что должно заполнить выделяемое место) и оптимизируют это размещение на стадии дисковой подсистемы. Разработчику преаллокатора в торрент-клиенте, например, приходиться балансировать между скоростью преаллокации (записи специально сформирвоанного потока байтов — фактически псевдорандомного мусора) и временем ответной реакции на начало скачивания торрент-контента. То есть грамотная преаллокация заключается в том, чтобы перед началом скачивания торрент-контента (допустим, 10ГБ MKV) нужно каким-то образом скинуть на диск поток байтового мусора, чтобы ФС точно выделила (10ГБ) желательно в соседних секторах диска этот самый объём пространства, которое со временем будет перезаписано настоящими байтами контента.

Однако современные ФС не учитывают физическое расположение секторов на диске (оперируют только LBA адресацией). И грамотный преаллокатор поэтому написать невозможно, как, кстати, и грамотный дефрагментатор с учётом расположения секторов на диске. Возможно лишь "балансировка" (оптимизация) метаданных для как можно скорейшего доступа к блокам с данными на диске.

Условно скорость доступа к данным повышается, если их располагать как можно ближе к логическому началу диска. С этим знанием ведут работу всякого рода дефрагментаторы и оптимизируют свою работу ФС при записи данных, а также учитывают другие критерии расположения: как можно более монотонная последовательность адресации блоков одного файла, как часто используется файл и, ещё может быть, размер файла (бывают дефрагментаторы, которые нарочно двигают большие файлы в конец или в начало диска). Всё это по сути ускоряет доступ к набору данных, но не делает этот доступ идеально быстрым — LBA скрывает механические перемещения головок винчестера. Работа с метаданными намного более продуктивна (быстра) и позволяет сделать время доступа к данным одинаковым на всей поверхности диска, обеспечить достаточную скорость чтения и записи (примерно в два раза меньше максимально доступной для данного винчестера) по ВСЕЙ поверхности диска.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
  Введите код, изображенный на картинке: КОД
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру