Страница 2 из 2

Добавлено: 29 янв 2006, 05:22
bazil
насчет дефрагментации: это в принципе даст вам прирост производительности 1-3% и не стоит износа веника и времени.

Добавлено: 29 янв 2006, 12:56
sergei_d
Gnida писал(а):Semiono, на вкус и цвет товарищей нет. про панельку в пол экрана это КДЕ?? засранцы , я так и знал , что они отбивают всю охоту пользоваться линуксом у новичков.
Разумеется, ведь новички не знают, что панельку можно сделать в 24 пиксела высотой, автоматически убирать с экрана и т.д... Честно говоря, мне тоже непонятно, зачем её такую здоровую делать. Кроме того, мне почему-то не нравится, когда эта панелька внизу экрана (немедленно перетаскиваю её вверх). :)

Добавлено: 29 янв 2006, 14:04
Semiono
Благодарю за советы! Буду переходить потихоньку, как на 2ю ось,т.к. Steinberg Nuendo замены небудет, но остальное интригующе!
А всётаки как свой винт увидеть "монтировать" и как войти как root?
mount o umount ws [а здесь что (fat32 C: D: E: ...)] у меня NOPPIX DVDRom стартует?
Speed Disk был самый лучший в Win98, а в WinNT ему всё лучшее
отрезали, теперь никаких опций, тупое дефрагментирование, как и другие Deeskiper Pro, O&O Defrag, mst Defrag, PerfectDisk, VoptXP...
Вообще то я туплю, вбил себе в голову идею, чтоб данные попрядку на винте были, пора об этом забыть :D 3-4% пользы

Добавлено: 29 янв 2006, 14:23
bazil
Semiono, меньше. На домашней системе -- результат может быть обратный

Добавлено: 29 янв 2006, 21:40
Semiono
Кое какой прогресс есть :)
_http://linuxmusic.ru/news.php
_http://ardour.org/
надо ещё больше и ещё сильнее подумать... [:beer:]

Добавлено: 29 янв 2006, 22:21
Semiono
Цытата:
"В 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 5.0 для NT. Когда его пытаются сравнить со всеми остальными - Diskeeper, O&O defrag, т.д. - не упоминают этого главного, самого принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере уж точно не афишируется на каждом шагу. Speeddisk - единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места. Стоит добавить также, что при помощи стандартного API невозможно дефрагментировать тома NTFS с кластером более 4 Кбайт, а SpeedDisk и это может.
К сожалению, в Windows 2000 поместили дефрагментатор, который работает через API, и, соответственно, плодит дырки <16 кластеров. Так что как только появится (если еще не появился) - так сразу надо качать Speeddisk для W2k.
Как некоторый вывод из всего этого: все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз - нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации новоприбывающих файлов. В этом основная суть сложности дефрагментации NTFS теми средствами, которые сложилисьисторически."
:(

Добавлено: 30 янв 2006, 08:19
Akeeri
Насчёт вышеизложенного - полная фигня. эта проблема только для сжатых файлов.