информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Все любят медГде водятся OGRы
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Google закрывает безлимитные Photos 
 Имя компании как средство XSS-атаки 
 Утекший код XP и Windows Server... 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / software
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Здесь ситуация несколько иная... 08.02.05 11:40  Число просмотров: 2060
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 08.02.05 11:43  Количество правок: 1
<"чистая" ссылка>
> Оптимизация ускоряет дисковые процессы - это по моему миф.
> Когда файлы кешируются, то по барабану как они лежат на
> диске. Разве что первое прчтение будет занимать чуть больше
> времени.
> Про сервак я вообще молчу. Когда куча пользователей
> работают каждый со своим файлом, то по барабану
> фрагментирован ли каждый из них или непрерывен, все равно
> головка дергаться будет.
На сервере РЕЙД 5 стоит еще и со своим кешем, а как он (РЕЙД 5) распределяет физически по диску блоки - одному РЕЙДУ известно. Представители Интел на конференциях "скромно" обходят этот вопрос. И вопрос дефрагментации рейда. Информация ИМХО конфенденциальная.

> То же самое с копированием большого количества файлов -
> головка дергается по фатам, каталогам и содержимым файлов,
> и собственно по барабану дернется ли она в то же самое
> место при считывании очередной порции файла или в другое.
в НТФС нет фата. есть MFT. И особенность работы такова, что при оставшемся свободном месте менее 15%, это место выделяется для данных, те происходит фрагментация MFT, что может сильно снизить производительность. Для серверов с одиночным или зеркальным диском ситуация возможна и она произошла из за ошибок в планирование дискового пространства (базы 1с положили на системный диск и они разрослись до почти полного "забоя" дискового пространства).

> И нечего мучить диск оптимизацией из-за мнимого копеечного
> выигрыша производительности при работе.
Головка то будет дергаться, но у привода головки есть свой ресурс и снижение нагрузки на привод может привести увеличению срока службы диска, а при большом ИТ парке к некоторой экономии бюджета.
При достаточно высокой стоимости серверной мощности оптимизация или исправление просчетов (лучше их не допускать:-) могут принести значительную экономию.
ЗЫ: Я не призываю делать плановую (например ежемесячную) дефрагментацию. Ресурс диска при этом также пострадает. Но исправить просчет и вернуть плановую производительность ИМХО надо.
ЗЫЫ: я заметил достаточно ощутимый прирост скорости закрузки ОС в2к на рабочей станции со слабой мощностью после дефрагментации. Сотрудник доволен, начальство то же (несколько продлен срок службы компа за незначительные ресурсы) :-)
<software>
Программа дефрагментации НТФС. 07.02.05 17:10  
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
преамбула отсюда http://www.ixbt.com/storage/ntfs.html
"Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий - после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку <16 кластеров размером. Которую потом невозможно заполнить через API дефрагментации! В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации - одна дыра в конце диска, и много маленьких <16 кластеров дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно, находящиеся ближе к началу диска мелкие дырки <16 кластеров... Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз.. и еще.. и так - желательно каждую неделю. Бред? Реальность.
......
Пока есть всего один дефрагментатор, который игнорирует API дефрагментации и работает как-то более напрямую - Norton Speeddisk 5.0 для NT. Когда его пытаются сравнить со всеми остальными - Diskeeper, O&O defrag, т.д. - не упоминают этого главного, самого принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере уж точно не афишируется на каждом шагу. Speeddisk - единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места. Стоит добавить также, что при помощи стандартного API невозможно дефрагментировать тома NTFS с кластером более 4 Кбайт, а SpeedDisk и это может.

К сожалению, в Windows 2000 поместили дефрагментатор, который работает через API, и, соответственно, плодит дырки <16 кластеров. Так что как только появится (если еще не появился) - так сразу надо качать Speeddisk для W2k.

Как некоторый вывод из всего этого: все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз - нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации новоприбывающих файлов."

Амбула
статья за 2000 год. изменилось что нибудь с другим софтом? Не могу никак найти новой информации.

Очень интересует софтинка под ДОС (или загрузочный образ под Линукс) дефрагментирующий НТФС без болезни описанной выше.
Стыдно вспомнить, но в молодости я тоже занимался... 08.02.05 11:08  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
Стыдно вспомнить, но в молодости я тоже занимался оптимизацией.
Оптимизация ускоряет дисковые процессы - это по моему миф. Когда файлы кешируются, то по барабану как они лежат на диске. Разве что первое прчтение будет занимать чуть больше времени.
Про сервак я вообще молчу. Когда куча пользователей работают каждый со своим файлом, то по барабану фрагментирован ли каждый из них или непрерывен, все равно головка дергаться будет.
То же самое с копированием большого количества файлов - головка дергается по фатам, каталогам и содержимым файлов, и собственно по барабану дернется ли она в то же самое место при считывании очередной порции файла или в другое.
И нечего мучить диск оптимизацией из-за мнимого копеечного выигрыша производительности при работе.
Здесь ситуация несколько иная... 08.02.05 11:40  
Автор: Garick <Yuriy> Статус: Elderman
Отредактировано 08.02.05 11:43  Количество правок: 1
<"чистая" ссылка>
> Оптимизация ускоряет дисковые процессы - это по моему миф.
> Когда файлы кешируются, то по барабану как они лежат на
> диске. Разве что первое прчтение будет занимать чуть больше
> времени.
> Про сервак я вообще молчу. Когда куча пользователей
> работают каждый со своим файлом, то по барабану
> фрагментирован ли каждый из них или непрерывен, все равно
> головка дергаться будет.
На сервере РЕЙД 5 стоит еще и со своим кешем, а как он (РЕЙД 5) распределяет физически по диску блоки - одному РЕЙДУ известно. Представители Интел на конференциях "скромно" обходят этот вопрос. И вопрос дефрагментации рейда. Информация ИМХО конфенденциальная.

> То же самое с копированием большого количества файлов -
> головка дергается по фатам, каталогам и содержимым файлов,
> и собственно по барабану дернется ли она в то же самое
> место при считывании очередной порции файла или в другое.
в НТФС нет фата. есть MFT. И особенность работы такова, что при оставшемся свободном месте менее 15%, это место выделяется для данных, те происходит фрагментация MFT, что может сильно снизить производительность. Для серверов с одиночным или зеркальным диском ситуация возможна и она произошла из за ошибок в планирование дискового пространства (базы 1с положили на системный диск и они разрослись до почти полного "забоя" дискового пространства).

> И нечего мучить диск оптимизацией из-за мнимого копеечного
> выигрыша производительности при работе.
Головка то будет дергаться, но у привода головки есть свой ресурс и снижение нагрузки на привод может привести увеличению срока службы диска, а при большом ИТ парке к некоторой экономии бюджета.
При достаточно высокой стоимости серверной мощности оптимизация или исправление просчетов (лучше их не допускать:-) могут принести значительную экономию.
ЗЫ: Я не призываю делать плановую (например ежемесячную) дефрагментацию. Ресурс диска при этом также пострадает. Но исправить просчет и вернуть плановую производительность ИМХО надо.
ЗЫЫ: я заметил достаточно ощутимый прирост скорости закрузки ОС в2к на рабочей станции со слабой мощностью после дефрагментации. Сотрудник доволен, начальство то же (несколько продлен срок службы компа за незначительные ресурсы) :-)
Слово "фрагментация" можно применять только к файловой... 08.02.05 13:22  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> На сервере РЕЙД 5 стоит еще и со своим кешем, а как он
> (РЕЙД 5) распределяет физически по диску блоки - одному
> РЕЙДУ известно. Представители Интел на конференциях
> "скромно" обходят этот вопрос. И вопрос дефрагментации
> рейда. Информация ИМХО конфенденциальная.

Слово "фрагментация" можно применять только к файловой структуре. К РЭЙДу этот термин не применим. От комментариев воздержусь.

> в НТФС нет фата. есть MFT. И особенность работы такова, что

Все равно это таблица с информацией о размещении файлов. Структура принципиально другая смысл содержимого абсолютно идентичный. Как эту таблицу не назови, в любой ФС есть такая табличка.

> при оставшемся свободном месте менее 15%, это место
> выделяется для данных, те происходит фрагментация MFT, что
> может сильно снизить производительность. Для серверов с
> одиночным или зеркальным диском ситуация возможна и она
> произошла из за ошибок в планирование дискового
> пространства (базы 1с положили на системный диск и они
> разрослись до почти полного "забоя" дискового
> пространства).

У каждой ФС есть свои преимущества и недостатки. Причем преимущества могут себя проявить недостатками при определенной ситуации.

> Головка то будет дергаться, но у привода головки есть свой
> ресурс и снижение нагрузки на привод может привести
> увеличению срока службы диска, а при большом ИТ парке к
> некоторой экономии бюджета.

Если диск не тянет трех лет непрерывной работы с максимальной нагрузкой, значит он неправильно спроектирован или бракованный.

> При достаточно высокой стоимости серверной мощности
> оптимизация или исправление просчетов (лучше их не
> допускать:-) могут принести значительную экономию.

Другими методами можно добиться бОльшего экономического эффекта.

> ЗЫ: Я не призываю делать плановую (например ежемесячную)
> дефрагментацию. Ресурс диска при этом также пострадает. Но
> исправить просчет и вернуть плановую производительность
> ИМХО надо.

Файловый кэш колосально снижает нагрузку на диск. Операционная система должна оптимизировать перемещение головки.

> ЗЫЫ: я заметил достаточно ощутимый прирост скорости
> закрузки ОС в2к на рабочей станции со слабой мощностью
> после дефрагментации. Сотрудник доволен, начальство то же
> (несколько продлен срок службы компа за незначительные
> ресурсы) :-)

РС загружаются раз в день, серваки раз в год. Без разницы что 10 секунд будет грузиться, что 100 секунд, что 10 минут.
При загрузке ОС принимают участие в основном системные файлы, а они как правило нефрагментированы, лежат друг за другом, "близко" друг от друга (если считать расстояние в целиндрах), да еще в начале диска.
ре:Слово "фрагментация" можно применять только к файловой... 08.02.05 16:01  
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
> Слово "фрагментация" можно применять только к файловой
> структуре. К РЭЙДу этот термин не применим. От комментариев
> воздержусь.
Я рассматривал систему в комплексе. ИМХО неучитывать особености носителя (контроллер+диски) нельзя. Компаковский Смартаррай с 4-мя дисками в РЕЙД 5 (27 гб) на запрос дефрагментации пошуршал винтами и выдал "готово" через несколько сек. Делал ли реально он что с инфой или выдал статус "готово"? Вот в чем вопрос. ИМХО статус:-)

> Все равно это таблица с информацией о размещении файлов.
> Структура принципиально другая смысл содержимого абсолютно
> идентичный. Как эту таблицу не назови, в любой ФС есть
> такая табличка.
ФАТ таблица не может фрагментироваться по стандарту, МТФ может и это приводит к снижению производительности.

> У каждой ФС есть свои преимущества и недостатки. Причем
> преимущества могут себя проявить недостатками при
> определенной ситуации.
Что есть - то есть:-)

> Если диск не тянет трех лет непрерывной работы с
> максимальной нагрузкой, значит он неправильно спроектирован
> или бракованный.
А он должен работать с максимальной нагрузкой. У десктопных винтов ПВ (продолжительность включения) не 100%. Но не это главное. Серверные SCSI винты расчитаны на 100% ПВ, но время жизни сервера (7-8 лет) больше гарантийного срока винта и приходится их "беречь":-)

> > При достаточно высокой стоимости серверной мощности
> > оптимизация или исправление просчетов (лучше их не
> > допускать:-) могут принести значительную экономию.
>
> Другими методами можно добиться бОльшего экономического
> эффекта.
Примеры? А если еще к "другими методами" добавить и этот - хуже не будет

> Файловый кэш колосально снижает нагрузку на диск.
> Операционная система должна оптимизировать перемещение
> головки.
Файловый кеш не дешево обходится, особенно для РЕЙД контроллеров, а еще и с батарейкой.

> РС загружаются раз в день, серваки раз в год. Без разницы
> что 10 секунд будет грузиться, что 100 секунд, что 10
> минут.
Разница есть, простые смертные юзвери оценивают качество работы ИТ отдела в удобстве (но не в ущерб безопасности). Иногда имеет тенденцию опаздывать и быстрая загрузка реалибитирует их в глазах нач отделов. Еще встречаются форс мажоры по важной отгрузке/тендерам/клиенте и выключении света. Явный пример: ХР при равных достаточных условиях грузится быстрее в2к. Программеры МС оптимизировали процесс загрузки ОС. Если бы фактор быстрой закгрузки не был бы важен в бизнес процесе - вряд ли бы МС заморачивалась бы с этим:-)

> При загрузке ОС принимают участие в основном системные
> файлы, а они как правило нефрагментированы, лежат друг за
> другом, "близко" друг от друга (если считать расстояние в
> целиндрах), да еще в начале диска.
Не факт. При "чистой" системе это так, но после установке СП и хотфиксов после начала использования кома - может начаться фрагментация. К системным можно отнести и доустановленные сервисы, стартующие при запуске системы, которые в свою очередь, через некоторое время, также патчаться и фиксятся.
http://www.raxco.com/products/perfectdisk2k/ в режиме... 07.02.05 21:50  
Автор: leo <Леонид Юрьев> Статус: Elderman
<"чистая" ссылка>
http://www.raxco.com/products/perfectdisk2k/ в режиме консолидации free-space
1






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2020 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach