Привет всем!
Хочу поделиться тезисами, которые должны снять вопрос с повестки дня...
Заранее пардон за тривиальные суждения и тавтологии.
1. АКСИОМА - фрагментация файлов, как явление, существует в любых
файловых системах, поддерживающих хранение файла в нескольких несмежных
непрерывных участках. Другими словами, если для размещения файла длиной N
логических блоков НЕ ТРЕБУЕТСЯ наличия N идущих подряд свободных логических
блоков.
2. Фрагментация в широком смысле есть не вредное_явление, как думают
многие, а качественное_свойство файловой системы.
3. ОСНОВНЫЕ ЗАДЕРЖКИ на уровне файловой системы происходят не при
чтении-записи данных, а при открытии-закрытии файлов! Потому, куда выгодней
дефрагментировать не область хранения данных, а системную область, где
хранятся сами внутренние структуры ФС. Под FAT16/32 это давало очень
заметный прирост в скорости поиска-открытия файлов. Под NTFS5 тоже дает,
хотя почему-то этот эффект меньше. На Униксовых файловых системах несколько
иная структура хранения системной информации, позволяющая выполнять поиск
"заголовка" файла гораздо быстрее, чем в ФАТ и НТФС.
4. Я совсем не уверен, что замеры производительности на реальных
задачах дадут "экономически" заметное различие для фрагментированных и
нефрагментированных экземпляров файловых систем. По моим наблюдениям, в
реальной работе файл-сервера пользователи больше ждут не 'Gatheringa'
раскиданных по диску кластеров (кэширование-то работает!), а снятия
блокировок другого пользователя. Особенно в отстое типа одинЦ или
фокспро-совместимых домочадах.
По крайней мере, при типичной офисной загрузке моих серверов (под Win2000AS
и ASP Linux Vostok + SAMBA 2.2.8) визуальные задержки и средняя длина
очередей запросов к диску после дефрагментации никак не меняется...
5. При работе с большим количеством примерно одинаковых небольших
файлов, занимающих небольшое количество кластеров (а имеено это происходит в
реальной офисной работе!), вероятность фрагментации вообще невелика. -
просто новый файл займет место какого-нибудь недавно стертого. Многие
менеджеры ФС (NTFS5, например, EXT3 по-моему тоже) при создании небольшого
файла выделяют сразу непрерывную область, размер которой вычисляется по
некоей формуле, вроде MAX(Lsysmin; Lreqested*K)
Конечно, в идеальном случае в таблице размещения файлов у каждого кластера
должен быть особый атрибут - "зарезервирован под рост файла". Смутно
помнится, где-то я даже видел что-то подобное...
6. При работе с большими файлами на сильно забитых дисках... Все равно
операция ввода-вывода будет долгой. Так чего зря суетиться?
7. При работе на сервере какой нибудь СУБД (типа Oracle или MS SQL
Server) файлы создаются специальной утилитой, которая при запросе к ОС на
создание файла сразу просит много, и ОС ищет непрерывный кусок. А лучше для
этого использовать неразмеченный раздел... Многие так и делают.
8. Стратегий размещеняи файлов в свободных местах много. Эта тема
потянет на диссертацию...
9. Насчет дефрагментации данных - лично я, вместо консолидации файлов в
начале диска делал бы с точностью до наоборот - рассредотачивал данные по
различным областям диска (например: длинные - в конец, средние - в начало,
короткие -в середину) , перемежая между собой занятые и свободные фрагменты
примерно одинаковой длины. Подумайте, и поймете "зачем". Насколько я понял
идеологию ReiserFS, её авторы отталкивались от сходных постулатов, хотя
пошли по другому пути.
10. Единственная серьёзная проблема, которая может "вылезти" на сильно
фрагментированном томе - это крайне сложное восстановление данных после сбоя
диска (при потере системных областей). Но - во-первых, это и так форс-мажор,
во-вторых, бэкапы надо делать, а в третьих, в журналируемых системах
хранения типа той же НТФС "глубокие" отказы ФС маловероятны. У меня за много
лет эксплуатации была только одна совсем печальная история - когда сделали
суперсверхдешевый сервер под Вынь2000, и ИДЕ Квантум 20ГБ от натуги просто
запилил середину диска (а там у НТФС как раз находится логическое начало
тома - мастер-запись, таблица размещения файлов и пр... ) Кстати, он в
"полуотказе" проработал месяца два, как потом выяснилось по остаткам
системных логов... Часть данных вытащил с помощью ZARtool, но большую часть
похоронил - большая часть MFT и файлов-директориев не читалась физически (на
спец. стенде). Вот так вот. Не экономьте на ХаДэДэ!
На моей памяти, систем, НЕ ПОДДЕРЖИВАЮЩИХ фрагментацию, было мало:
- CP/M, CP/M-86;
- RT-11,FODOS,RAFOS и им подобные для PDP-11 (про ОС РВ для СМ-4/1420 не
скажу - не помню...); RSX-11 - уже с фрагментацией
- большинство т.н. Rommable-FS и Flashable-FS, применяющихся во встроенных
контроллерах, где совсем нет места для сложного программного кода;
- совсем старые операционки, про которые все забыли...
Вот на них как раз и приходилось периодически-обязательно запускать всякие
там Squeeze и т.п. утилитки, иначе был велик риск того, что следующий файл
размером больше 1 блока просто не запишется.
Вкратце, все.
Извините, если не в тему.
Бест регардс, Игорь Гаврилюк
-*Название листа "Обсуждения и споры о свободных системах и всём сопутствующем"
Написать в лист: comp.soft.linux.debate-list@subscribe.ru
Архив Листа - http://subscribe.ru/archive/comp.soft.linux.debate Поиск: http://www.google.com
Адрес правил листа http://subscribe.ru/catalog/comp.soft.linux.debate/rules
Номер письма: 1307; Возраст листа: 240; Участников: 583
Адрес сайта рассылки: http://www.linuxrsp.ru
Адрес этого письма в архиве: http://subscribe.ru/archive/comp.soft.linux.debate/msg/173513
-*Информационный канал Subscribe.Ru
Написать в лист: mailto:comp.soft.linux.debate-list@subscribe.ru
Отписать : mailto:comp.soft.linux.debate--unsub@subscribe.ru
http://subscribe.ru/ mailto:ask@subscribe.ru
