Список форумов Шадринский форум -> Отдел игрушек (мягких и твёрдых) -> Операционные системы и сети -> NTFS разделы не требуют дефрагментации?
NTFS разделы не требуют дефрагментации?
Автор
Сообщение
| Хм... В топике веплюса (http://forum.shadrinsk.net/viewtopic.php?t=89&start=285) был затронут вопрос о том, что NTFS разделы не нужно дефрагментировать... Мне кажется это сомнительным, применительно к компьютеру, как к рабочей станции. Хотелось бы услышать мнение пользователей форума по этому вопросу... |
| в общем случае - не надо. |
Не Microsoft ли ты послушал, прийдя к такому выводу?..  Исходя из особенностей строения файловой системы NTFS сделать вывод о неподверженности её фрагментации файлов могла только Microsoft… Сейчас такие заявления они дать уже не осмелятся и максимум, что они могут говорить сейчас, так это то, что: «NTFS препятствует фрагментации». Правда это тоже не совсем так.
Пока-что я уверен в одном: Рабочие станции дефрагментировать необходимо, а сервера трогать не стоит… На серверах работающих с множеством небольших файлов некоторая степень фрагментации – положительным образом сказывается на производительности файловой системы. Дело в том, что сервера – это множество запросов, прерывающих один другой, т.е. обращения к дискам в таких условиях уже в некоторой степени хаотично. Однажды была собрана специальная группа, целью которой было определить оптимальную энтропию файловой системы для разного рода серверов и создать ПО для искусственной фрагментации их файловой системы для приближения к этой энтропии. У них ничего не получилось, кроме как доказать пагубные последствия дефрагментации. По поводу фрагментации NTFS писать долго, так что процитирую один из моих источников: Сейчас уже понятно, что NTFS - система, которая как никакая другая предрасположена к фрагментации, что бы ни утверждалось официально. Единственное что - логически она не очень от этого страдает. Все внутренние структуры построены таким образом, что фрагментация не мешает быстро находить фрагменты данных. Но от физического последствия фрагментации - лишних движений головок - она, конечно, не спасает. Как известно, система сильнее всего фрагментирует файлы когда свободное место кончается, когда приходится использовать мелкие дырки, оставшиеся от других файлов. Тут возникает первое свойство NTFS, которое прямо способствует серьезной фрагментации. Диск NTFS поделен на две зоны. В начала диска идет MFT зона - зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется - зона сокращается ровно в два раза  . И так далее. Таким образом мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном на около 90% - фрагментация растет как бешенная.
Попутное следствие - диск, заполненный более чем на 88%, дефрагментировать почти невозможно - даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет свободного места для маневра. Далее. NTFS работает себе и работает, и всё таки фрагментируется - даже в том случае, если свободное место далеко от истощения. Этому способствует странный алгоритм нахождения свободного места для записи файлов - второе серьезное упущение. Алгоритм действий при любой записи такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем по очень интересному алгоритму: сначала заполняются большие дырки, потом маленькие. Т.е. типичное распределение фрагментов файла по размеру на фрагментированной NTFS выглядит так (размеры фрагментов): 16 - 16 - 16 - 16 - 16 - [скачек назад] - 15 - 15 - 15 - [назад] - 14 - 14 - 14 .... 1 - 1 - 1 -1 - 1... Так процесс идет до самых мелких дырок в 1 кластер, несмотря на то, что на диске наверняка есть и гораздо более большие куски свободного места. Вспомните сжатые файлы - при активной перезаписи больших объемов сжатой информации на NTFS образуется гигантское количество "дырок" из-за перераспределения на диске сжатых объемов - если какой-либо участок файла стал сжиматься лучше или хуже, его приходится либо изымать из непрерывной цепочки и размещать в другом месте, либо стягивать в объеме, оставляя за собой дырку. Смысл в сего этого вступления в пояснении того простого факта, что никак нельзя сказать, что NTFS препятствует фрагментации файлов. Наоборот, она с радостью их фрагментирует. Фрагментация NTFS через пол года работы доведет до искреннего удивления любого человека, знакомого с работой файловой системой. Поэтому приходится запускать дефрагментатор. Но на этом все наши проблемы не заканчиваются, а, увы, только начинаются... В NT существует стандартное API дефрагментации. Обладающее интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров (!), причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия: В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это неинтересные в данный момент тонкости). Файл, будучи перемещенный в другое место, оставляет после себя (на новом месте) "временно занятое место", дополняющее его по размеру до кратности 16 кластерам. При попытке как-то неправильно ("не кратно 16") переместить файл результат часто непредсказуем. Что-то округляется, что-то просто не перемещается… Тем не менее, всё место действия щедро рассыпается "временно занятым местом". "Временно занятое место" служит для облегчения восстановления системы в случае аппаратного сбоя и освобождается через некоторое время, обычно где-то пол минуты. Тем не менее, логично было бы использовать это API, раз он есть. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, состоит из следующих фаз (не обязательно в этом порядке): Вынимание файлов из MFT зоны. Не специально - просто обратно туда их положить не представляется возможным Безобидная фаза, и даже в чем то полезная.
Дефрагментация файлов. Безусловно, полезный процесс, несколько, правда, осложняемый ограничениями кратности перемещений - файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму. Дефрагментация MFT, виртуалки (pagefile.sys) и каталогов. Возможна через API только в Windows2000, иначе - при перезагрузке, отдельным процессом, как в старом Diskeeper-е. Складывание файлов ближе к началу - так называемая дефрагментация свободного места. Вот это - воистину страшный процесс... Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий - после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку <16 кластеров размером. Которую потом невозможно заполнить через API дефрагментации! В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации - одна дыра в конце диска, и много маленьких <16 кластеров дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно, находящиеся ближе к началу диска мелкие дырки <16 кластеров... Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз.. и еще.. и так - желательно каждую неделю. Бред? Реальность. Таким образом, имеется два примерно равнозначных варианта. Первый - часто оптимизировать диск таким дефрагментатором, смиряясь при этом с дикой фрагментацией заново созданных файлов. Второй вариант - вообще ничего не трогать, и смириться с равномерной, но гораздо более слабой фрагментацией всех файлов на диске. Пока есть всего один дефрагментатор, который игнорирует API дефрагментации и работает как-то более напрямую - Norton Speeddisk. Когда его пытаются сравнить со всеми остальными - Diskeeper, O&O defrag, т.д. - не упоминают этого главного, самого принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере уж точно не афишируется на каждом шагу. Speeddisk - единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места. Стоит добавить также, что при помощи стандартного API невозможно дефрагментировать тома NTFS с кластером более 4 Кбайт, а SpeedDisk и это может. К сожалению, в Windows 2000 поместили дефрагментатор, который работает через API, и, соответственно, плодит дырки <16 кластеров. Так что как только появится (если еще не появился) - так сразу надо качать Speeddisk. Как некоторый вывод из всего этого: все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз - нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации новоприбывающих файлов. В этом основная суть сложности дефрагментации NTFS теми средствами, которые сложились исторически. |
Джем писал(а): Не Microsoft ли ты послушал, прийдя к такому выводу?.. Джем писал(а): Сейчас уже понятно, что NTFS - система, которая как никакая другая предрасположена к фрагментации, что бы ни утверждалось официально. Единственное что - логически она не очень от этого страдает. Все внутренние структуры построены таким образом, что фрагментация не мешает быстро находить фрагменты данных. Но от физического последствия фрагментации - лишних движений головок - она, конечно, не спасает.и, пожалуйста, без той воды, которую щедро разлил в предыдущем сообщении. |
| Субъективно, интенсивность нагрузки на винчестер среднестатистического пользователя после проведения дефрагментации падает ощутимо, если это не производилось месяца 3. На моём винчестере это в прямом смысле слышно - он громкий.
При проведении дефрагментации есть возможность выиграть в свободном месте... Так как фрагменты стоят зарезервированных блоков. При 70% заполненности диска мы можем высвободить большие блоки свободного пространства, чтобы записываемые файлы не раскидывались по небольшим фрагментам. Самый большой бич фрагментированности NTFS - лишние движения головок. |
| всё было бы так, если бы не одно НО. система многозадачная, всё равно подряд винт файлы не читает, то один читанёт, то другой. а также имеется дисковый кэш как в винте, так и в ОСи, для держания в себе фата, мфт и т.п. плесени. потому дефрагментированы файлы или нет - сути не меняет.
смотрел высосаные из пальца тесты. ускорение работы системы от 5% до 20% на только что дефрагментированном винте. вопрос: зачем тратить время на дефрагментацию, если она не мешает? |
| Ссылки на тесты - в студию! А насчёт того, что она не мешает - я тебе дал 4 предложения по пагубному фоздействию фрагментации. Принимать это за помеху или нет - личное дело каждого.
Насчёт многозадачности ты, конечно, прав, но ещё раз оговорюсь, я говорю про рабочую станцию... Пользователь редко запускает две тяжёлые программы интенсивно работающие с дисковой подсистемой. Всё, по идее, что тут говорится, может иметь оговорки и недосказанности, потому как обсуждается проблема в общем... Т.е. абстрагироваться нужно в разумных пределах. Вот ссылка (http://www.execsoft.com/whats-new/Win2K-Final-nov99.PDF) на тест группы, которой я доверяю. По крайней мере - пока не было причин недоверия. Приросты производительности налицо... Тест несколько синтетичен и аппаратно устарел, но базовые понятия, на которые он основывается будут действенны, пока мы не уйдём с IDE и с Windows NTFS. Последний раз редактировалось: Джем (2005.02.28 16:28.01), всего редактировалось 1 раз |
| 4 предположения?
1. первое нечто субъективное (тем более не ясен характер твоих занятий). 2. как это можно выйграть в свободном месте?? обоснуй, а то получается что после дефрагментации больше места на винте становится
3. не ясно. ну высвободим и чё? зачем? ps: NTFS-диски не рекомендуется заполнять более чем на 80% (вроде бы). 4. смешно. при чем тут NTFS? типа фрагментированность на райзере меньше движений вызывает . ответ смотри в предыдущем сообщении. повторяю: система многозадачная. движения этих головок есть всегда. а меньше или больше - это уже СУБЪЕКТИВНО. теоретически возможна такая фрагментация, при которой быстродействие УВЕЛИЧИТСЯ.
pps: ссылка-от где? |
| попробую предположить. ты (наверно) ссылаешься на тест, где виндофса 2000 проф бета 2 гоняли на пне про втором? так там смех, а не тесты: 128 метров озу (ха, на систему-то мало, вы туда еще нтфс), спецом фрагментированный своп (при таком-то колве озу). филькина грамота, а не тест. кстати и то, при таком тесте увеличение производительности кот наплакал. в одном месте у них получилось в 2 раза, на Pentium Pro 233 MHz, 128 МБ, на каких-то экселефских файлах.
естесственно, NTFS требует памяти (не много, но чтоб была), это вам не FAT32, и очень желательно что бы винт не заполнялся более 88%, иначе даже дефрагментатор не запустится. впрочем, при такой заполненности любая FS будет фрагментироваться и тормозить. так что не убедил ты, Джем, в необходимости дефрагментации. _________________ Ин дер гросен фамилие нихт клювен клац-клац  |
| 1. Как и сказано, - субъективно.
2. Каждый фрагмент файла в конце имеет хвост занятости дополнения до кратности 16 кластеров. Большее число фрагментов плодит большее число зхвостов. Естественно, эта проблема решается только дефрагментаторами, работающими не через WinAPI. 3. Объясни это пользователю, который покупал 200Gb винт чтобы использовать 160?... 4. При чём тут ReizerFS? Мы говорим про NTFS. У каждой системы - свои тонкости... А фильм разлившийся по тысячам фрагментов - это не красиво, если он будет лежать долго... 5. Ссылку на исследование добавил в предыдущий пост. 6. Ещё раз, ссылки на тесты в студию! |
| 1. ты читать-то будешь? не для всех типов работ дефрагментация не важна.
2. ссылку на стандарт 3. не понял. объясни п.2, а этот вытекает из предыдущего 4. "некрасиво" - это не аргумент. тем более этого просто не видно и не заметно. 5. о да, я именно про этот тест и говорил. так что мнение об этом тесте я уже говорил. 6. ты сам её привел _________________ Ин дер гросен фамилие нихт клювен клац-клац |
| Хех... не знаю удобно ли вмешаться... =) я конечно не специалист... но особо сильного падения производительности на моем ПК при продолжительном непроведении дефрагментации (строго говоря, я ее вообще практически никогда не провожу) я не наблюдал... все работает как работает... правда диск у меня поделен на раздел данных и системный, и когда я переустанавливаю систему то все сношу с системного... в принципе, своего рода дефрагментация. =) но она бывает не чаще раза в 6 - 7 месяцев.
так что лично я не пользуюсь дефрагментацией. не знаю уж, требуют разделы NTFS ее или нет, но я ее не провожу |
| Учтём, что большинство рабочих станций работает так, что файл подкачки, система и данные расположены на одном разделе... Рано или поздно виртуальная память при стандартных, т.е. динамических, настройках её объёма начнёт фрагментироваться... Конечно, правильно - фиксировать размер файла подкачки, а то и вовсе его ложить на физически другой винчестер...Но это делают "просвещённые" единицы.
Самая большая уязвимость для производительности файловой системы NTFS - фрагментация MFT (Master File Table), для которой изначально резервируется 12,5% от объёма диска. (Начиная с NT4 SP4 этот параметр варьируем). Даже при однократном заполнении жёсткого диска до 60-70 процентов размер выделенной под MFT зоны уменьшается и если файл будет записан туда (а как бы туда и надо, так как там физическая скорость HDD выше) то при высвобождении пространства и, соответственном увеличении зарезервированного объёма под MFT, выделение произойдёт в любом доступном свободном блоке. И если так будет происходить несколько раз, то получим хорошее снижение производительности NTFS разделов.... Ведь MFT для них - святое... Да что тут говорить? Microsoft сама советует регулярно производить дефрагментацию. Не зря она включила Execsoft Deskeeper (оччень урезанный) в стандартный комплект поставки Windows. Не зря расписывает, что фрагментированные разделы работают не так хорошо, как те, которые регулярно дефрагментируются. На официальном сайте расписано об ускорении работы файловой системы (http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prkc_fil_punq.asp) |
Джем писал(а): (а как бы туда и надо, так как там физическая скорость HDD выше) |
andy ice писал(а): Джем писал(а): (а как бы туда и надо, так как там физическая скорость HDD выше)Поясни. И ещё, не нужно думать, что если этим не заниматься, то - капут. NTFS - хорошо сбалансированная система. То, что тут обсуждается очень большого прироста не сделает. Просто если машинка - "не ахти" - то можно поизголяться... Да и запускать сильно не стоит тоже... 6-7 месяцев - это терпимо, учитывая что резких скачков снижения производительности не будет... субъективно, многие вообще не оценивают даже большую разницу в скорости "по приборам"... |
| ты мне объясни, откуда ФС знать, где ФИЗИЧЕСКАЯ скорость выше? ты вот сам-то знаешь? _________________ Ин дер гросен фамилие нихт клювен клац-клац |
Джем писал(а): Каждый фрагмент файла в конце имеет хвост занятости дополнения до кратности 16 кластеров.
ну я ваще фигею. ааа. ну блин. ну ёмаё (с) прапор из Солдат |
| извините, вмешаюсь.
у меня нтфс. винт не дефрагментировался 2.5 года. когда поцепили второй, новый (на нем тоже нтфс), то скорость между ними была всего 7-9 мегабайт/с. Решил провести стандартную дефрагментацию. после нее скорость возрасла на порядок между винтами и стала от 25 до 40 мегабайт в секунду. я для себя сделал вывод, что все же дефрагментация помогает для увеличения производительности винта. получаем прирост производительности налицо. |
andy ice писал(а): ты мне объясни, откуда ФС знать, где ФИЗИЧЕСКАЯ скорость выше? ты вот сам-то знаешь?IMHO, в "начале" диска она всегда выше, чуть ли не в два раза на средних моделях. Посмотри обзоры любого издательства, занимающегося обзором HDD... (www.ixbt.com) На низком уровне драйвер любой ФС работает с "архаичными" секторами, дорожками, кластерами... Т.е. они знают, где на "блинах" винтов "теплое местечко"... А MFT - 12,5% (по умолчанию) "начала" диска. |
andy ice писал(а): Джем писал(а): Каждый фрагмент файла в конце имеет хвост занятости дополнения до кратности 16 кластеров.
ну я ваще фигею. ааа. ну блин. ну ёмаё (с) прапор из Солдат Логически - один. Физически (я имел в виду конец фрагментов так-то) - сколь угодно (в разумных пределах так-то)... |
Джем писал(а): andy ice писал(а): Джем писал(а): Каждый фрагмент файла в конце имеет хвост занятости дополнения до кратности 16 кластеров.
ну я ваще фигею. ааа. ну блин. ну ёмаё (с) прапор из Солдат Логически - один. Физически (я имел в виду конец фрагментов так-то) - сколь угодно (в разумных пределах) так-то... |
| на, почитай.
http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us/W2K3TR_ntfs_how.asp _________________ Ин дер гросен фамилие нихт клювен клац-клац |
интернет писал(а):
NTFS — система, которая как никакая другая предрасположена к фрагментации, что бы ни утверждалось официально. Единственное — логически она не очень от этого страдает. Все внутренние структуры построены таким образом, что фрагментация не мешает быстро находить фрагменты данных. Но от физического последствия фрагментации — лишних движений головок — она, конечно, не спасает. и ещё интернет писал(а): В NT существует стандартное API дефрагментации, обладающее интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров (!), причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия:
1. В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это неинтересные в данный момент тонкости). 2. Файл, будучи перемещенный в другое место, оставляет после себя (на новом месте) "временно занятое место", дополняющее его по размеру до кратности 16 кластерам. 3. При попытке как-то неправильно ("не кратно 16") переместить файл результат часто непредсказуем. Что-то округляется, что-то просто не перемещается... Тем не менее, все место действия щедро рассыпается "временно занятым местом". "Временно занятое место" служит для облегчения восстановления системы в случае аппаратного сбоя и освобождается через некоторое время, обычно где-то полминуты. Тем не менее, логично было бы использовать это API, раз он есть. Его и используют. Поэтому процесс стандартной дефрагментации, с поправками на ограниченность API, состоит из следующих фаз (не обязательно в этом порядке): Вынимание файлов из MFT зоны. Не специально — просто обратно туда их положить не представляется возможным . Безобидная фаза, и даже в чем-то полезная.
Дефрагментация файлов. Безусловно, полезный процесс, несколько, правда, осложняемый ограничениями кратности перемещений — файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму. Дефрагментация MFT, виртуалки (pagefile.sys) и каталогов. Возможна через API только в Windows2000, иначе — при перезагрузке, отдельным процессом, как в старом Diskeeper-е. Складывание файлов ближе к началу — так называемая дефрагментация свободного места. Вот это — воистину страшный процесс... Допустим, мы хотим положить файлы подряд в начало диска. Кладем один файл. Он оставляет хвост занятости дополнения до кратности 16. Кладем следующий — после хвоста, естественно. Через некоторое время, по освобождению хвоста, имеем дырку <16 кластеров размером, которую потом невозможно заполнить через API дефрагментации! В результате, до оптимизации картина свободного места выглядела так: много дырок примерно одинакового размера. После оптимизации — одна дыра в конце диска, и много маленьких <16 кластеров дырок в заполненном файлами участке. Какие места в первую очередь заполняются? Правильно, находящиеся ближе к началу диска мелкие дырки <16 кластеров... Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз… и еще… и так — желательно каждую неделю. Бред? Реальность. Таким образом, имеется два примерно равнозначных варианта. Первый — часто оптимизировать диск таким дефрагментатором, смиряясь при этом с дикой фрагментацией заново созданных файлов. Второй вариант — вообще ничего не трогать и смириться с равномерной, но гораздо более слабой фрагментацией всех файлов на диске. _________________ Скажи мне чей Крым, и я скажу кто ты. |
Zema
Заслуженный писатель
Пол:
Зарегистрирован: 25.11.2004
Сообщения: 1623
Откуда: Отсюда
Статус: Offline
Заслуженный писатель
Пол:
Зарегистрирован: 25.11.2004
Сообщения: 1623
Откуда: Отсюда
Статус: Offline
Джем писал(а):
3. Объясни это пользователю, который покупал 200Gb винт чтобы использовать 160?... А и в правду объясните!У меня HDD 120Gb,разбит на два 20 и 100,на одном FAT 32, а на втором NTFS.Получается, что сотку можно забить тока до 80, а дальше не рекомендуется?  |
| не рекомендуется - это не запрещается _________________ Ин дер гросен фамилие нихт клювен клац-клац |
| Забить то ты можешь и на 100, только будут траблы. А если забьешь 20 полностью - то вероятней всего работать не сможешь вообще. _________________ Скажи мне чей Крым, и я скажу кто ты. |
Zema
Заслуженный писатель
Пол:
Зарегистрирован: 25.11.2004
Сообщения: 1623
Откуда: Отсюда
Статус: Offline
Заслуженный писатель
Пол:
Зарегистрирован: 25.11.2004
Сообщения: 1623
Откуда: Отсюда
Статус: Offline
| То есть , если я сотку полностью заполню, я не смогу сделать ей дефрагментацию?Но перед онной я могу что-нибудь удалить или переместить на 20-ку. |
Я раз делал дефрагментацию на полном винте - и он умер 
Зато я познакомился с Ларри
и с sm-ом _________________ Скажи мне чей Крым, и я скажу кто ты. |
Zema
Заслуженный писатель
Пол:
Зарегистрирован: 25.11.2004
Сообщения: 1623
Откуда: Отсюда
Статус: Offline
Заслуженный писатель
Пол:
Зарегистрирован: 25.11.2004
Сообщения: 1623
Откуда: Отсюда
Статус: Offline
Leon писал(а): Я раз делал дефрагментацию на полном винте - и он умер
Зато я познакомился с Ларри
и с sm-ом Наверно ты сделал дефрагментацию на ихнем винте!На котором какой-нибудь хостинг сидел? Ты же хотел как лучше, а получилось как всегда?  |
| Нет - винт был мой. _________________ Скажи мне чей Крым, и я скажу кто ты. |
Страница 1 из 2
Список форумов Шадринский форум -> Отдел игрушек (мягких и твёрдых) -> Операционные системы и сети -> NTFS разделы не требуют дефрагментации?
| |
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах Вы не можете вкладывать файлы Вы можете скачивать файлы |