Какая файловая система быстрее убивает диск? Как продлить срок службы жесткого диска? В этой статье мы постараемся дать вменяемые ответы на вопросы по выбору и разметке файловой системы для более производительной и продолжительной службы HDD...
Срок службы жесткого диска (HDD) как и его производительность напрямую зависит от выбора файловой системы, способа её разметки, а также разумеется активности и условий использования.
Какая файловая система больше подвержена фрагментации?
Все файловые системы подвержены фрагментации, независимо от типа используемой ОС - вот так вот!:) Почему? Да потому, что на свежий/пустой диск данные пишутся в каждую следующую за предыдущей свободную единицу хранения данных - кластер (блок, зона). Со временем старые данные удаляются, а новые записываются на их место - например мы удалили файл размером в 5 мб., который был расположен в средине массива уже записанных данных, значит между данными образовалась "дыра" в 5 мб., теперь пишем на диск файл размером в 10 мб., который одной своей половиной занимает "дыру" в 5 мб., а под остальные 5 мб. свободное место ищется где-то там. Подробнее читаем в Дефрагментация диска.
Достоверно известно, что ФС FAT более подвержена фрагментации, чем ФС NTFS. Для ОС Linux/BSD в настоящее время рекомендуются ФС ext4/ufs, которые имеют свои механизмы препятствующие фрагментации, но не исключающие её! Например файловая система ext4 имеет механизм пространственной (extent) записи файлов, уменьшающий фрагментацию и повышающий производительность.
Для флеш-накопителей рекомендуется exFAT (Extended FAT), но её поддержка возможна только в ОС семейства Windows - другими словами на ОС типа Linux/BSD чтение данных с exFAT будет невозможным!
Выбор файловой системы, способ разметки и настройка
С выбором файловой системы мы определились - это NTFS для Windows и ext4/ufs для Linux/BSD. Большую роль в увеличении срока жизни HDD играет не только сам тип файловой системы (FAT/NTFS/UFS etc), но и способ разметки, а также тонкая её настройка.
Под способом разметки имеется ввиду выбор замера кластера перед форматированием диска. При записи файла на диск, он пишется в первый же свободный кластер, который в свою очередь состоит из секторов диска.
В операционных системах Windows размер кластера (зоны в Minix, блоки в Unix), в файловой системе NTFS, при котором возможно сжатие, составляет 512-4,096 байт и по умолчанию при форматировании равен 512 б, т.е. 1 кластер состоит из 1 сектора (в большинстве дисков 1 сектор = 512 б). Если размер кластера для ФС NTFS выше 4,096 байт, то сжатие файлов будет не доступно! Максимальный размер кластера/блока как для NTFS так и для UFS2/FFS равен 64 кб..
Например, мы имеем файловую систему отформатированную с размером кластера по умолчанию (512 байт, 1 сектор), то при записи файла занимающего более 1-го кластера, скажем файла размером 2048 б (2 КБ), магнитным головкам диска нужно будет сделать дополнительную работу и отыскать ближайший свободный кластер на что разумеется тратится время и ресурс жизни диска, а также увеличивается фрагментация файлов.
Таким образом, при маленьком размере кластера и регулярном удалении/записи, большие файлы просто говоря "размазываются" по всему жесткому диску, что разумеется замедляет их чтение/запись, а также сокращает срок жизни HDD. Значит желательно иметь несколько разделов, под различные типы файлов, с различным размером кластера - например для хранения мультимедиа файлов можно создать раздел с максимальным, для NTFS, размером кластера в 64 кб., а под системный взять стандартный размер кластера в 512 или поднять до 1024-2048 б.
Отметим, что чем большего размера кластер, тем меньше места занимает "Master File Table" (MFT) и тем быстрее работает ФС, но нужно также иметь ввиду, что каждый фай или каталог занимает полностью как минимум 1 кластер - т.е. если ФС отформатирована кластерами по 4 КБ, то при создании пустого текстового файла в 0 КБ он будет фактически занимать 4 КБ (один кластер), а при большом количестве пустых файлов на ФС с кластерами в 4 КБ или более сами наверное догадываетесь.., да - в файлах будет пусто и место на жестком диске быстро закончится!
Помимо предустановочной подготовки жесткого диска нужно выяснить перечень параметров, которые регулируют поведение/работу файловой системы - например для ФС NTFS (Windows) это NtfsAllowExtendedCharacterIn8dot3Name, NtfsDisable8dot3NameCreation, NtfsDisableLastAccessUpdate, для ФС EXT3/EXT4 (UNIX-like) это commit=120,noatime,nodiratime,barrier=0,nobh,nouser_xattr и т.п..
Размещение файлов на жестком диске.
Немаловажным является место размещения файлов на жестком диске. Систему лучше размещать в самом начале жесткого диска, ближе к 0-му сектору потому, что эта область шире в диаметре, где одна дорожка способна разместить в себе наибольшее число данных, а значит за один оборот диска магнитная головка сможет считать с такой одной дорожки больше информации и за менее короткий промежуток времени, чем с дорожки меньшего диаметра расположенной ближе к центру диска!
В самом-самом начале лучше размещать файл подкачки, а в следующем разделе уже саму ОС - т.е. под первый создаваемый раздел (обычно всегда "C") выбелить 2-4 ГБ с максимальным размером кластера в 64 кб, а в следующий "D" уже ставить саму ОС.
Лучше использовать один файл подкачки и разумеется размещать его в начале диска. При наличии нескольких файлов подкачки они оба используются системой.
Дефрагментация жестких дисков (HDD)
Почти все вещества в умеренных дозах могут быть лекарством - так и с дефрагментацией. Дефрагментация жесткого диска только по необходимости, когда результатом анализа является сообщение о необходимости дефрагментации, также может продлить срок жизни жесткому диску сократив/упорядочив место используемое файлами.
Во время дефрагментации диска выполняется перемещение, разбросанных по всему диску, частей файлов в одну кучу, т.е. как можно плотнее друг к другу, что сокращает диапазон размаха магнитных считывающих головок жесткого диска при чтении данных, а следовательно увеличивается скорость чтения и продлевается срок жизни HDD.
Частая дефрагментация "вредит" диску HDD, сокращает срок его жизни и при особо фанатичном подходе диск можно просто "зарезать"!
Циклы включения/выключения/перезагрузки ПК
Многие сись. администраторы заметили закономерное различие сроков жизни жестких дисков (HDD) в зависимости с количеством включения/выключения/перезагрузки ПК. Там, где ПК включался/выключался/перезагружался чаще, там жесткие диски (HDD) накрывались тоже чаще, а на ПК с "аптаймом" 80-100% жесткие диски (HDD) жили в 2-3 раза дольше.
Поэтому для продления срока службы жесткого диска желательно ПК вовсе не выключать, а монитор установить на отключение после 5-20 мин. простоя, но в таком случае повысится износ материнской платы и её компонентов, а также расходы на электроэнергию. Для предотвращения быстрого износа материнской платы и её компонентов при 80-100% аптайме желательно вокруг ПК обеспечить температуру +15/+20С - больше или меньше не рекомендуется, также желательно каждые 2-3 мес. чистить от пыли и пр..
Немного про "Несколько оптимизирующих твиков Windows"
Под ОС семейства Windows по сети "скитается" некий DWORD параметр ContigFileAllocSize который по идее должен быть расположен в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem и указывающий в десятичной системе мин. размер в КБ запрашиваемого неразрывного дискового пространства под запись файла. Другими словами - мы помним что файл пишется т.с. куда попало кусками мин. в один кластер, после записи первого куска/кластера/блока данных запрашивается место под второй, так вот DWORD параметр ContigFileAllocSize якобы устанавливает мин. размер куска (неразрывного дискового пространства), который должна найти система перед началом записи файла.
Сейчас мы будем разрушать мифы про ContigFileAllocSize:
- Сей параметр работоспособен только для Windows 98 и упоминается только на одной единственной оф. странице http://support.microsoft.com/kb/835821/ru;
- Значение параметра устанавливается в КилоБайтах, а не Байтах;
- На ос Windows XP эта фича не работает - проверено, установкой максимально допустимого DWORD значения для ContigFileAllocSize, которое было равно 4294967295 (0xffffffff), при этом система нормально загрузилась и никаких проблем с записью/чтением не возникало (пространства было свободно 2 ГБ из 10-ти), хотя при превышении значения в 4,048 пугали как минимум проблемами с записью, а то и вовсе невозможностью загрузить WindowsXP/2000.
Теперь ещё про "Несколько оптимизирующих твиков Windows", где относительно всё того же ContigFileAllocSize тупо копи/пастица вот такая ересь:
На производительность файловой системы влияет и размер записываемого блока данных. По умолчанию Windows сбрасывает данные в первый попавшийся свободный участок величиной 512 килобайт. Затем происходит обращение к файловой системе о выделении следующих 512 Кбайт и т.д. Видно, что при такой работе происходит дефрагментация диска, и тратится время на запрос и поиск пространства. Поэтому рекомендуется увеличить не менее чем вдвое размер свободного пространства, запрашиваемого системой для записи. В этом случае прирост производительности будет заметнее при работе с файлами большого объёма. Размер свободного пространства лучше выбирать в интервале 1024-4096 килобайт с учётом объёма винчестера.
Вот так и ширится ересь - один где-то тупо содрал и разосрлал по всей сети, третий подхватил и пошло/поехало... Но, мы то ведь знаем, что:
- Файл пишется в первую свободную единицу хранение данных, которыми оперирует ОС, а не "в первый попавшийся свободный участок величиной 512 килобайт";
- Операционные системы, в качестве единицы хранения информации, оперируют кластерами (зоны в Minix, блоки в Unix/Linux);
- Кластеры (зоны в Minix, блоки в Unix/Linux) состоят из секторов диска, а сектора в свою очередь у разных жестких дисков могут иметь различный размер, но обычно это 512 байт.
Не хочу обижать афтора, может он просто по ошибке вместо "512 байт" написал "512 килобайт" и "Видно, что при такой работе происходит дефрагментация диска" вместо "Видно, что при такой работе происходит фрагментация файлов", но по факту грешное с праведным реально попутано, более того сам DWORD параметр ContigFileAllocSize к Windows XP (скорее всего также и к 2000/7) никакого отношения не имеет, который не упоминается и в оф. документации к упомянутой ОС и не влияет на её работу, что проверено опытным путем в Windows XP!
Скажу однозначно то, что в сети дофига шлака и часто казалось бы на якобы авторитетных и мега посещаемых веб-ресурсах, печатают откровенную МЕГА-ХРЕНЬ вокруг которой часто разгораются нехилые и затяжные "холивары", поэтому нужно уметь фильтровать получаемую инфу иначе тупое следование инструкциям типа "Несколько оптимизирующих твиков Windows" может обеспечить скоропостижный "кирдык" Вашему ПК, а это убитое железо, потерянное время, похудевший кошелёк и порванные на попе волосы!:)
У нас, в отличии от некоторых, только проверенная инфа, а кто не согласен пишите свои аргументы в комментарии!:)
