Исходное сообщение
"Оценка производительности ZFS-FUSE в сравнении с EXT4 и Btrf..." Отправлено аноним, 03-Сен-10 02:32
не верно. по скольку уже выяснили, что zfs совсем не обязатльно иметь блок размером именно в 128к. также логично предположить, что время выделения блока любого размера из перечисленных - это О(1). более того, для бтр в 32М блоков по 4к большее количество получается, чем для zfs по 128к. опять же, любое прикладное по не выделяет блоки, оно просто передает порцию данных для io (объектом же является весь файл, а не его куски), соответственно сколько блоков выделять, в каком количестве и как это согласуется с конкретным физ.девайсом, секторами, головками и пр. поэтому ваше предположение, что zfs не умеет этого делать - хм, смешно как минимум. т.е. абсолютно не факт, что если вы пишете в файл порциями по N, то и блок будет по N. еще раз прочтите (про ахилесову пяту zfs - SLAB): >The central on-disk data structure was the slab - a chunk of disk divided up into the same size blocks, like that in the SLAB kernel memory allocator, which he also created. Instead of extents, ZFS would use one block pointer per block, but each object would use a different block size - e.g., 512 bytes, or 128KB - depending on the size of the object. вот все его плюсы и минусы в популярном изложении http://en.wikipedia.org/wiki/Slab_allocation >Slab – объем памяти, за счет которого кэш может увеличиваться или уменьшаться. Он представляет собой распределение памяти в кэш, а его размер обычно кратен размеру страницы памяти. Slab должен содержать список свободных буферов, а также список буферов, которые были выделены (в случае большого размера slab’а). так что панацея отменяется.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> не верно. по скольку уже выяснили, что zfs совсем не обязатльно иметь > блок размером именно в 128к. также логично предположить, что время выделения > блока любого размера из перечисленных - это О(1). более того, для > бтр в 32М блоков по 4к большее количество получается, чем для > zfs по 128к. опять же, любое прикладное по не выделяет блоки, > оно просто передает порцию данных для io (объектом же является весь > файл, а не его куски), соответственно сколько блоков выделять, в каком > количестве и как это согласуется с конкретным физ.девайсом, секторами, головками и > пр. > поэтому ваше предположение, что zfs не умеет этого делать - хм, смешно > как минимум. > т.е. абсолютно не факт, что если вы пишете в файл порциями по > N, то и блок будет по N. > еще раз прочтите (про ахилесову пяту zfs - SLAB): >>The central on-disk data structure was the slab - a chunk of disk divided up into the same size blocks, like that in the SLAB kernel memory allocator, which he also created. Instead of extents, ZFS would use one block pointer per block, but each object would use a different block size - e.g., 512 bytes, or 128KB - depending on the size of the object. > вот все его плюсы и минусы в популярном изложении http://en.wikipedia.org/wiki/Slab_allocation >>Slab – объем памяти, за счет которого кэш может увеличиваться или уменьшаться. Он представляет собой распределение памяти в кэш, а его размер обычно кратен размеру страницы памяти. Slab должен содержать список свободных буферов, а также список буферов, которые были выделены (в случае большого размера slab’а). > так что панацея отменяется.
	Введите код, изображенный на картинке: