Исходное сообщение
"Обновление ZFSonLinux 0.6.0-rc10, реализации ZFS для ядра Li..." Отправлено Аноним, 26-Авг-12 16:26
> Ну то слегка, будут выделены максимально линейные фрагменты. Вообще, если том на 99% забить, как этот чудик, с этим будет небогато. И даже классика начнет валиться в такой же по смыслу штопор. Менее сурово, но начнет. Я такое даже видел, хоть это и постараться надо. > А при каче торрента на ZFS или просто без преаллокации каждый ~1-16Мб > (в лучшем случае) блок ляжет в отдельное место диска, без оглядки на линейность. Непрерывный блок на 16Мб - это достаточно неплохо, механический диск вполне в состоянии десяток seek в секунду сделать и будет читать на практически максимальной скорости. Но в торрентах бывает и блок 64К, вот тут с тупым клиентом (который не буфферизует вообще ничего) начнется ахтунг. Тут даже классика с экстентами начнет задыхаться от прорвы метаданных. Кстати чисто теоретически, CoW при преаллокации мог бы рассмотреть это как хинт: ага, они собираются писать в этот файл так и сяк. А давайте фрагменты стараться раскладывать друг за другом, в соответствии с их смещением в файле?! Ну то-есть даже CoW вполне мог бы резервировать непрерывный "виртуальный прообраз" файла (который заказали преаллокацией) и по нему раскладывать "паззл" из фрагментов по мере их поступления. Вполне себе CoW логикой. Благо, CoW логике все-равно куда именно фрагмент класть. Можно класть не абы как а чуть более удобно. Почему нет? Другое дело что не все возможные оптимизации аллокации реализованы вот сей момент.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Ну то слегка, будут выделены максимально линейные фрагменты. > Вообще, если том на 99% забить, как этот чудик, с этим будет > небогато. И даже классика начнет валиться в такой же по смыслу > штопор. Менее сурово, но начнет. Я такое даже видел, хоть это > и постараться надо. >> А при каче торрента на ZFS или просто без преаллокации каждый ~1-16Мб >> (в лучшем случае) блок ляжет в отдельное место диска, без оглядки на линейность. > Непрерывный блок на 16Мб - это достаточно неплохо, механический диск вполне в > состоянии десяток seek в секунду сделать и будет читать на практически > максимальной скорости. Но в торрентах бывает и блок 64К, вот тут > с тупым клиентом (который не буфферизует вообще ничего) начнется ахтунг. Тут > даже классика с экстентами начнет задыхаться от прорвы метаданных. > Кстати чисто теоретически, CoW при преаллокации мог бы рассмотреть это как хинт: > ага, они собираются писать в этот файл так и сяк. А > давайте фрагменты стараться раскладывать друг за другом, в соответствии с их > смещением в файле?! Ну то-есть даже CoW вполне мог бы резервировать > непрерывный "виртуальный прообраз" файла (который заказали преаллокацией) и по нему раскладывать > "паззл" из фрагментов по мере их поступления. Вполне себе CoW логикой. > Благо, CoW логике все-равно куда именно фрагмент класть. Можно класть не > абы как а чуть более удобно. Почему нет? Другое дело что > не все возможные оптимизации аллокации реализованы вот сей момент.
	Введите код, изображенный на картинке: