Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
Однозначный ответ: Мало разницы для современных ОС, но, как... 18.08.06 11:30 Число просмотров: 2852
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 18.08.06 11:40 Количество правок: 7
|
Однозначный ответ: Мало разницы для современных ОС, но, как правило, скорость работы незначительно уменьшится. Причем, как не смешно, средняя скорость работы с большими файлами на "большом" разделе будет все-таки больше, если данные находятся в начале диска, чем на "маленьком", располагающимся в конце диска.
> Как примерно соотносятся размер раздела и скорость доступа
> к нему? Скорость доступа к разделу уменьшается
> пропорционально увеличению размера?
Смысл вопроса и ответов вполне понятен, при работе группа рабочих файлов одного активного приложения как правило располагается на одном разделе. В процессе работы имеет место быть фрагментация данных как одного файла, так и группы файлов приложения. Если данные "размазываются" по всему радиусу, то работа с данными будет значительно медленнее. Ко всему этом полезно сказать о том, что к накладным расходам на перемещение головок для доступа к данным добавляется перемещение головок для работы с таблицами размещения данных, свободных областей и каталогами.
> Например, если винчестер 250 ГБ, как его лучше разбить?
> Поделить на 5 разделов по 50 ГБ, или озадачиться этим
> вопросом? Т.е. для раздел с ОС сделать поменьше, с
> файлопомойкой побольше. Имеет ли это смысл?
Эх, (извиняюсь) "Задница" опередил. Поскольку имеет место быть иногда "падение" ОС и "проверка/лечение файловой система", то хорошим тоном будет отведение одного небольшого раздела для ОС. Удобно сделать образ для восстановления, удобно/быстро прочекается системный раздел, удобно чекается (без перезагрузки) раздел с данными.
Эх, и Дмитрий опрередил. Только суть поясню. Выигрыш производительности от разбиения все равно очень мал. Если важна производительность, то нужно задумываться о быстрых дисках, контроллерах, массивах, а не о разбиении. К тому же бытует миф, что дефрагментация может повысить скорость работы с накопителем. Развею его. Если раньше (ДОС-ФАТ) на это еще можно было обращать внимание из-за необльших объемов оперативки и отсутствия интелектуального кеширования, то сегодня фрагментация не оказывает сильного влияния при интенсивной работе, поскольку данные и таблицы размещения файлов хорошо кешируются - пусть все данные наихудшим образом "размазаны" по диску, если они сядут в кеш, то не будет ни какой разницы от 100% дефрагментации и ее отсутствия.
К стати не было сказано о типе ФС. Если это EXT3 или NTFS5, где табицы находятся не в начале раздела (в отличии от ФАТ), а размазаны по диску вместе с файлами так, что табичка размещения файла находится рядом с данными, то размер раздела опять же будет играть еще меньшую роль, чем при использовании ФАТ даже при сильной фрагментации и малом кеше.
Короче вывод: разбить лучше, как удобнее - либо один большой раздел, чтоб не было трудностей с заливкой чего-то большого, когда на всех разделах в сумме будет достаточное свободное место, но ни на одном не будет достаточного, либо два - выделить отделно системный небольшой раздел; если же будет сильно важна скорость, то следует рассмотреть необходимость создания RAIDов из нескольких дисков. Если размер данных превышает объем оперативки, просто поставте еще один модуль и приложение "полетит", небольшое замедление можно будет заметить только при первичном обращении приложения к данным.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
