NTFS или причина простоя ?
C=5гб,FAT 32 (тут стоит винда и все)
вот и причина.
Дефрагментируй диск.
Вопрос 2: в какой момент наблюдаются тормоза? Когда начинает вылезать менюшка New..., или когда нажимаешь на папку, чтобы ее переименовать?
На С стоит только винда, а весь софт у меня на D.
На счет второго вопроса тормозит он в обоих случаях и когда говорю ему создать (он долго думает что же ему создать) и когда пытаюсь переименовать папку.
Кстати говоря еще одна бага, когда пытаюсь сделать анализ диска С перед дефрагментацией он очень долго его анализирует (около 15 минут хотя тот же Д который больше по размеру в 5 раз анализирует намного быстрее.
На счет второго вопроса тормозит он в обоих случаях и когда говорю ему создать (он долго думает что же ему создать) и когда пытаюсь переименовать папку.
Кстати говоря еще одна бага, когда пытаюсь сделать анализ диска С перед дефрагментацией он очень долго его анализирует (около 15 минут хотя тот же Д который больше по размеру в 5 раз анализирует намного быстрее.
На С стоит только винда
так же означает, что "Program Files\Common Files" и "%WINDIR%\System32" тоже живут у тебя на C. К файлам из именно этих директорий и происходит обращение, когда ты создаешь и переименовываешь папки.
Фат в целом это довольно тормознутая система, с плохо продуманной (но зато очень простой) структурой. Поэтому он тормозит, поэтому он сильно фрагментируется, поэтому его долго анализируют перед дефрагментацией. Пользуйся более свежими операционными системами. Фат практически не изменялся с 1981 года, нтфс - с 1993. Пользуйся более передовыми технологиями.
А вот я наблюдал, что если создавать папку в диалоге сохранения файла (такой стандартный диалог то тормозит жутко. Причем плевать NTFS или FAT даже на версию винды плевать. Если создавать в проводнике, то быстрее. Если в FAR то все ОК - то есть мгновенно.
если создавать папку в диалоге сохранения файла (такой стандартный диалог)
это так же означает, что запущено другое (возможно большое) приложение, которое жрет память.
Если создавать в проводнике, то быстрее.
Потому что это самое жрущее память приложение не запущено.
Если в FAR то все ОК
Потому что в FAR ты просто создаешь новую папку, а не выбираешь предварительно все типы объектов, которые ты можешь создать командой New (как это делает explorer). Обрати внимание, что после появления этого меню и выбора именно папки, создание папки происходит уже мнгновенно.
> Пользуйся более передовыми технологиями
Например?
Например?
Например, NTFS вместо FAT. Причем не сконвертированный раздел, а отформатированный изначально под NTFS (в чем большая разница - я уже писал недавно, при конвертации получается очень сильно фрагментированный MFT, который практически невозможно дефрагментировать)
Честно, я не знаю, что я делаю неправильно. Но у меня почему-то папки создаются моментально что из меню, что в диалоге "сохранить/открыть"...
Честно, я не знаю, что я делаю неправильно. Но у меня почему-то папки создаются моментально что из меню, что в диалоге "сохранить/открыть"...
у меня на диске есть папочка, в которой в подпапках где-то 100000 файликов вот она реально томозит при заходе в неё.
вот она реально томозит при заходе в неё.Лев, я это все понимаю. Но вечный вопрос: почему так криво?
Потому что для того, чтобы все сделать работающим правильно, быстро и удобно - необходимо много ресурсов. Но оплачивать эти ресурсы никто не хочет.
Фат в целом это довольно тормознутая система, с плохо продуманной (но зато очень простой) структурой. Поэтому он тормозит, поэтому , поэтому его долго анализируют перед дефрагментацией. Пользуйся более свежими операционными системами. Фат практически не изменялся с 1981 года, нтфс - с 1993. Пользуйся более передовыми технологиями.Можешь дать ссылки с тестами, подтверждающими твои выводы? А то просто все, что попадалось - утверждения вот такого же типа. А не катят они.
Теперь тезисы в защиту фата.
То, что он тормозной - бред. "Чистый" фат работает быстрее "чистого" нтфса.
Нтфс на партиции, заполненной более чем на 90% - это полный п..ц по скорости
Это нормально?Фат всегда можно нормально дефрагментировать, даже если винт забит вообще под завязку, что ж до нтфса - ты сам писал.
Фат дефрагментирутся быстрее(в этом не уверен, но у меня всегда так было)
То что нтфс "современнее" нихрена не означает, что он быстрее. Главное отличие нтфса - это наличие прав, что ну никак не может прибавить скорости. и не прибавляет
Что же до мифа о "ненадежности" фата - позапрошлый семестр электричество у меня падало от трех до 10 раз за вечер, система WinXP, FAT32, я не потерял ни байтика нужных мне данных.
В общем к чему это я. Давно хочу начать пользовацца "более передовыми технологиями", но все эксперименты меня не удовлетворяют - быстрее фат и все тут. По работе частенько приходится гонять большие объемы и кучи файлов, так что скорость весьма критична, комп сингл-юзерский - как и у большинства непараноиков, защита не впилась...
Ты сможешь меня аргументированно убедить, что мне нужен именно нтфс?(хинт - я хочу в этом убедиться, так что тупого флейма не будет)
имхо главный плюс нтфс - журналируемость и не надо сказки рассказывать про свет и сохранность данных.
и не надо сказки рассказывать про свет и сохранность данных.с этим я не спорю.
про свет - нихрена не сказки. меня реально два месяца ломало провести электричество от верхнего света. и потом, я не говорю, что у меня вообще ничего не про...лось. просто ничего нужного. а на типичном синглюзерском домашнем компе вообще редко бывает что-то реально нужное, да и нтфс для сохранения этого не подойдет - винты сейчас часто летают...
про свет - нихрена не сказки. меня реально два месяца ломало провести электричество от верхнего света. и потом, я не говорю, что у меня вообще ничего не про...лось. просто ничего нужного. а на типичном синглюзерском домашнем компе вообще редко бывает что-то реально нужное, да и нтфс для сохранения этого не подойдет - винты сейчас часто летают...
> журналируемость и не надо сказки рассказывать про свет и сохранность данных
про журналирование тут: http://unixfaq.ru/index.pl?req=qs&id=479
насколько мне известно, к windows всё это тоже применимо, по крайней мере с настройками по умолчанию
про журналирование тут: http://unixfaq.ru/index.pl?req=qs&id=479
насколько мне известно, к windows всё это тоже применимо, по крайней мере с настройками по умолчанию
какое такое изменение порядка выполнения на идешных хардах? только на айбиэмах и в планах на с-ата-2
тебя обманули
именно для этого и нужен write-back, именно поэтому и производительность добавляется
именно для этого и нужен write-back, именно поэтому и производительность добавляется
По пунктам.
Почему NTFS быстрее?
1. Способ выделения места под файлы организован таким образом, что файлы фрагментируются слабее, а маленькие файлы по возможности не фрагментируются вообще. На fat фрагментируются все файлы, независимо ни от чего.
2. Формат хранения директорий - b-tree, поиск файла в директории осуществляется быстрее, чем на fat.
3. Формат хранения занятыз блоков (MFT) организован более правильно, в результате поиск блоков, занятых файлом происходит практически моментально, по сравнению с FAT. (И в результате, кстати, сильно ускоряется процедура дефрагментации. Хочешь убедиться? Попробуй утилитой contig.exe (www.sysinternals.com) дефрагментировать один большой файл на FAT и один большой файл на NTFS. Разница в скорости считывания file allocation data примерно на порядок.)
Ни разу этого не наблюдал, даже на забитых под завязку партициях. Что я делаю не так?
Я писал, что практически невозможно дефрагментировать сильно фрагментированный MFT. Не путать с разделом. NTFS замечательно дефрагментируется. MFT - с трудом. Но только надо учесть, что единственный способ получить MFT, состояшую более чем из 1-5 фрагментов - это конвертировать диск из FAT в NTFS.
Почему NTFS быстрее?
1. Способ выделения места под файлы организован таким образом, что файлы фрагментируются слабее, а маленькие файлы по возможности не фрагментируются вообще. На fat фрагментируются все файлы, независимо ни от чего.
2. Формат хранения директорий - b-tree, поиск файла в директории осуществляется быстрее, чем на fat.
3. Формат хранения занятыз блоков (MFT) организован более правильно, в результате поиск блоков, занятых файлом происходит практически моментально, по сравнению с FAT. (И в результате, кстати, сильно ускоряется процедура дефрагментации. Хочешь убедиться? Попробуй утилитой contig.exe (www.sysinternals.com) дефрагментировать один большой файл на FAT и один большой файл на NTFS. Разница в скорости считывания file allocation data примерно на порядок.)
Нтфс на партиции, заполненной более чем на 90% - это полный п..ц по скорости. Это нормально?
Ни разу этого не наблюдал, даже на забитых под завязку партициях. Что я делаю не так?
что ж до нтфса - ты сам писал.
Я писал, что практически невозможно дефрагментировать сильно фрагментированный MFT. Не путать с разделом. NTFS замечательно дефрагментируется. MFT - с трудом. Но только надо учесть, что единственный способ получить MFT, состояшую более чем из 1-5 фрагментов - это конвертировать диск из FAT в NTFS.
Главное отличие нтфса - это наличие прав, что ну никак не может прибавить скорости. и не прибавляетИ опять ты не прав. Данные на разделе NTFS хранятся таким образом, что большой разницы между содержимым файла и его атрибутами (правами, потоками, и т.п.) просто нет. Доступ к атрибутам файла и т.п. осуществляется с такой же скоростью, как и доступ к самому файлу.
Что же до мифа о "ненадежности" фата - позапрошлый семестр электричество у меня падало от трех до 10 раз за вечер, система WinXP, FAT32, я не потерял ни байтика нужных мне данных.Наверное, ты очень везучий человек, что тут еще добавить.
Нет, он просто не открывает файлы с нужными данными на запись.Что же до мифа о "ненадежности" фата - позапрошлый семестр электричество у меня падало от трех до 10 раз за вечер, система WinXP, FAT32, я не потерял ни байтика нужных мне данных.Наверное, ты очень везучий человек, что тут еще добавить.
с дефрагментаций не все так однозначно:
...
Часть 2. Особенности дефрагментации NTFS
Вернемся к одному достаточно интересному и важному моменту - фрагментации и дефрагментации NTFS. Дело в том, что ситуация, сложившаяся с этими двумя понятиями в настоящий момент, никак не может быть названа удовлетворительной. В самом начале утверждалось, что 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 кластеров... Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз.. и еще.. и так - желательно каждую неделю. Бред? Реальность.
Таким образом, имеется два примерно равнозначных варианта. Первый - часто оптимизировать диск таким дефрагментатором, смиряясь при этом с дикой фрагментацией заново созданных файлов. Второй вариант - вообще ничего не трогать, и смириться с равномерной, но гораздо более слабой фрагментацией всех файлов на диске.
...
http://www.ixbt.com/storage/ntfs.html
Быстродействие FAT и NTFS
...
3. Выводы
В данн
...
Часть 2. Особенности дефрагментации NTFS
Вернемся к одному достаточно интересному и важному моменту - фрагментации и дефрагментации NTFS. Дело в том, что ситуация, сложившаяся с этими двумя понятиями в настоящий момент, никак не может быть названа удовлетворительной. В самом начале утверждалось, что 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 кластеров... Любой файл, плавно созданный на прооптимизированном диске, будет состоять из дикого числа фрагментов. Да, диск потом можно оптимизировать снова. А потом еще раз.. и еще.. и так - желательно каждую неделю. Бред? Реальность.
Таким образом, имеется два примерно равнозначных варианта. Первый - часто оптимизировать диск таким дефрагментатором, смиряясь при этом с дикой фрагментацией заново созданных файлов. Второй вариант - вообще ничего не трогать, и смириться с равномерной, но гораздо более слабой фрагментацией всех файлов на диске.
...
http://www.ixbt.com/storage/ntfs.html
Быстродействие FAT и NTFS
...
3. Выводы
В данн
Оставить комментарий
vuyko
Итак W2k, 256 мб памяти , 1400 МГц проц.Ничего не запущено (из программ говорю ему в проводнике создай папку и переименуй ее.
А он тормозит секунд 30. Если из под фара все это делаю то все нормально.
В чем проблема ? Я грешу на НТФС. Диск разбит так: C=5гб,FAT 32 (тут стоит винда и все) + D=25Гб,NTFS а тут все остальное.