Исходное сообщение
"Принято решение использовать в Fedora 16  по умолчанию файло..." Отправлено Я, 11-Июн-11 00:48
>> btrfs - файловая система общего назначения (в разумных пределах). > В каком-то роде так, но тащить такую фичастую хреновину на 10Гб том > - довольно странная идея. То-есть, в идеале хорошо бы учесть и > такой сценарий, но сильно надрываться для него имхо не актуально. У нее нет особого оверхера даже для такого сценария. Если отключить чексуммы: mount -o nodatasum и дублирование метаданных: mkfs -m single (фиг на них для portage), то мы вообще получим только выигрыш по сравнению с другими FS за счёт аккуратной упаковки файлов. >> Для маленьких систем (типа meego, или гентушнегу на /usr/portage) mixed - идеальный >> вариант. > А разве на портажах не будет дофига и больше метаданных? Там же > сорсы - мелкие файлы, размер метаданных сравним с размером данных. А > локализация данных и метаданных в неких областях по идее может ускорить > операции с ними (операции будут более последовательны). При современных объемах дисков > довольно странно было бы экономить копейки мегабайтов проиграв в скорости. Скорость только увеличится за счёт более плотной упаковки на диске. На ext4 portage в гигабайт трудно уместить из-за жирной таблицы инодов и внутренней фрагментации внутри блоков на диске. Уж в чём btrfs обвинить нельзя - так это в тормозах из-за неэффективности хранения. Пример: portage tree: 200 000 файлов (177MB), в среднем ~1.5KB каждый. Размер таблицы инодов: 200000 * 256 байт: 50MB; а их надо резервировать больше, ибо статические (это так парит!). Внутренняя фрагментация внутри блоков, выделенных под файл (если размер блока - 4KB) 200 000 * 2KB = 400MB. В сумме из-за фрагментации теряем 500MB. Не говоря о лишних seek. Итого на ext4 portage занимает 700MB. В случае с portage - да. Всё забито исключительно (присутствующими на диске в 2 экземплярах) метаданными, так как маленькие файлы хранятся прямо в том же месте с метаданными (inline), а блок с данными (~256MB) будет пустым. Но даже в таком режиме это занимает меньше места на диске (compress=lzo), чем с ext4: /dev/sda10            4,5G  1,1G  3,4G  24% /mnt/portage В этих 1.1G лежит: - исходник ядра на 474MB - portage (rsync) - 184MB - portage (CVS) - 168MB Чистый размер всего этого добра 819M (--mixed FS)

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>>> btrfs - файловая система общего назначения (в разумных пределах). >> В каком-то роде так, но тащить такую фичастую хреновину на 10Гб том >> - довольно странная идея. То-есть, в идеале хорошо бы учесть и >> такой сценарий, но сильно надрываться для него имхо не актуально. > У нее нет особого оверхера даже для такого сценария. Если отключить чексуммы: > mount -o nodatasum и дублирование метаданных: mkfs -m single (фиг на > них для portage), то мы вообще получим только выигрыш по сравнению > с другими FS за счёт аккуратной упаковки файлов. >>> Для маленьких систем (типа meego, или гентушнегу на /usr/portage) mixed - идеальный >>> вариант. >> А разве на портажах не будет дофига и больше метаданных? Там же >> сорсы - мелкие файлы, размер метаданных сравним с размером данных. А >> локализация данных и метаданных в неких областях по идее может ускорить >> операции с ними (операции будут более последовательны). При современных объемах дисков >> довольно странно было бы экономить копейки мегабайтов проиграв в скорости. > Скорость только увеличится за счёт более плотной упаковки на диске. На ext4 > portage в гигабайт трудно уместить из-за жирной таблицы инодов и внутренней > фрагментации внутри блоков на диске. > Уж в чём btrfs обвинить нельзя - так это в тормозах из-за > неэффективности хранения. > Пример: > portage tree: 200 000 файлов (177MB), в среднем ~1.5KB каждый. > Размер таблицы инодов: 200000 * 256 байт: 50MB; а их надо резервировать > больше, ибо статические (это так парит!). > Внутренняя фрагментация внутри блоков, выделенных под файл (если размер блока - 4KB) > 200 000 * 2KB = 400MB. > В сумме из-за фрагментации теряем 500MB. Не говоря о лишних seek. Итого > на ext4 portage занимает 700MB. > В случае с portage - да. Всё забито исключительно (присутствующими на диске > в 2 экземплярах) метаданными, так как маленькие файлы хранятся прямо в > том же месте с метаданными (inline), а блок с данными (~256MB) > будет пустым. > Но даже в таком режиме это занимает меньше места на диске (compress=lzo), > чем с ext4: > /dev/sda10 > 4,5G 1,1G 3,4G 24% /mnt/portage > В этих 1.1G лежит: > - исходник ядра на 474MB > - portage (rsync) - 184MB > - portage (CVS) - 168MB > Чистый размер всего этого добра 819M (--mixed FS)
	Введите код, изображенный на картинке: