кароче для оси проще купить SSD и не греть голову.

K9 Спасибо за ответ. Как я не догадался про папку Prefetch в толк не возьму?
BSWrama совет ну просто блеск! а чо всего-то SSD, может Gigabyte iRAM сразу.

вот ответ от авторов программы perfectdisk, на любой метод дефрагментации
As mentioned previously, all defragmenters use Microsoft's defrag APIs -
we have no control on how Microsoft implements the actual file "move".
переведите кому не лень

протестировал Defraggler вот результат
RamDisk 2GB, свободно 1 ГБ, фрагментация 50%, процесс длился 13 минут!!!
если на рамдиске в 2 гб 13 минут, то сколько лет это будет длиться на винте в 500гб?
видео процесса дефрагментации сокращённое по времени в 8 раз

BSWrama Так и не ясно что ты хочешь все же.

Harddm я хочу чтобы дефрагментация велась цилиндрами, а не файлами. я даже буду "за" использование другого диска для временных файлов.
понимая всю ущербность API от мокрософта, всё же я как понял пользователь может получить инфу о том где и какой кусок файла располагается, исходя из этой информации можно запросить у системы такую последовательность кусков, которая будет соответствовать 1 цилиндру. так можно сосчитать скажем 1 гиг инфы с харда, провести дефрагментацию и записать монолитный файл, по типа архива, на другом диске. а можно и обратно всё записать в уже более менее дефрагментированом виде. ну и так далее. на худой конец можно заменить библиотеку в которой записан стандартный апи и тогда ваще не греть голову

BSWrama Нууу...тогда тебе нужно написать самостоятельно программу дефрагментации.
Только на апи накопить нужно.

Harddm для начала мне нужно сменить деятельность, изучить програмирование, и т.д.

то, что работает - очень хорошая вещь. То, что работает хорошо лучше, чем то, что просто работает. То, что работает более чем хорошо надо использовать в повседневной практике. Есть такой чел J.Kessel он нарисовал очень интересный дефраг. API, естественно, MS, но алгоритм нивелирует заносы MS в части использования FrameWorkов в степени, превышающей необходимую. В результате после месяца работы с JKDefrag у меня на диске нарисовалась стройная картина, хотя сначала была мешанина. Все файлы теперь лежат в том порядке, в каком они должны лежать. Принцип, похоже, простой - самое часто используемое кладётся на последний край зоны у начала диска, нередактируемые часто используемые файлы - в начало диска. Нередактируемые файлы - в середину диска, а редко редактируемые файлы - в конец серединной зоны диска. Получается сортировка сама по себе. Принцип пузырька - школьная программа программирования.

А чем стандартный виндовский плох?

Olorin ну я на нём пока и остановился, ибо есть поддержка х64, ток он работает боже упаси как медленно. но всёравно красиво, что не говори. темнеменее меня интересует то что может использовать ресурсы системы хотя бы на 25% (2ГБ оперы )
Добавлено спустя 1 минуту, 13 секунд
Yngwest похоже тем что при дефрагментации читает не цилиндр, а кусочки файла, чем сильно изматывает головку харда + это жутко долго.

BSWrama если учесть, что при DMA это не достоинство, а недостаток, если автор хранит там куски данных... но если это под индексы алгоритма... то снимаю шляпу и шаркаю ножкой.

Olorin переведи на русский язык своё высказывание

чем занять два гига? - либо дефрагментируемым контентом, либо данными, генерируемыми алгоритмом дефрагментации (индексы расположения файлов).

если автор гоняет по узенькой шине данных проц-оперативка куски информации с жёсткого диска, это это ошибка изначально.
если это алгоритм позволяет формировать такой глубины индексы под анализ... остаётся только преклонить колено перед программером WinAPI в законе.

Olorin почему канал опера-проц узкий? или ты опять на китайском выражаешься? и причём тут индексы? они то ващет не нужны, при дефрагментации гоняются сами данные а не индексы.

т.е. ты хочешь сказать, автор должен каждый раз читать MFT, например, чтобы узнать, где файл лежит? Или ты хочешь сказать, что у автора нет таблицы нового расположения файлов? Если так, то это новость. Индекс и правда по-китайски. Таблица расположения файлов. Копия MFT лежит в оперативке в авторстве драйвера файловой системы, а вот новая таблица и промежуточные таблицы расположения файлов при анализе текущего расположения файлов кладутся автором программы-дефрагментатора.

Второе - это у АМД гипертранспорт уже сейчас. Интел только приходит к такому подходу. Через 16 бит шины DMI или HT 1ггц нифига не протянешь особо крупного. А чтобы дефрагментировать файл, его данные надо пару раз прогнать через эту шину, если не использовать DMI и прямое перемещение через буфер жёсткого.

Olorin вот теперь перевёл точнее сказал то что не могли сказать другие.
из чего я делаю вывод, что апи гоняет данные посредством DMI, типа чтобы машинку не грузить...
а теперь считаем стоит ли грузить машинку или нет?
скорость чтения с харда 100мб/сек
скорость записи на хард 100мб/сек
чтобы сосчитать 2ГБ требуется 20 сек, и чтобы записать тоже 20 сек. и того минута на полную дефрагментацию.
теперь практика (тест на своём компе)
копирование файла из диска 1 на диски 2,3,4,5,6,7 одновременно, размер файла 1ГБ
затраченное время 15 сек.
400мб/сек!!! и кто сказал что это место узкое???
в этом то и проблема что буфер харда 16-32мб, и в нём много не поместишь, а у системы оперы может быть дохренища.
по мне так проще для дефрагментации 500гб прогнать через машинку 1тб, за 15 минут, нежели вечность смотреть как трещит винт

Все очень грамотно расписано ,но обьясните как часто требуется дефрагментация для например самого обычного домашнего компьютера и почему BSWrama так беспокоится о времени дефрагмнтации?

Harddm потому что если у тя хард 750ГБ и свободно несколько метров, то начинается жуткая картина, которая продолжается в перспективе неделю...
Добавлено спустя 1 минуту, 23 секунды
при том что фрагментировать данные можно оч быстро и нечайно.

в целом идея неплохая. Главное, учитывать, что можно и электричество отключить. Вдруг. Результат - у тебя до хрена файлов по 1,3 гига. На харде свободно 1 гиг. Все файлы по 1,3 фрагментированы. Если ты скопировал в память, хорошо. Теперь попробуй его запиши так, чтобы при отключении электричества не потерять данные. Надо сначала получить общую картину, а потом предлагать. Если на харде есть необходимое нефрагментированное свободное место, теоретически, можно использовать твой способ. Но когда писали алгоритмы для дефрагментаторов не было ещё такого размера оперативки. Алгоритм: прочитать файл, записывая его в охренительного размера переменную, записать на поверхность в новое место одним фрагментом, сменить адрес в MFT на новый, после чего перекомпоновать мелкие файлы по схожему алгоритму в одну кучу на поверхности и дефрагментировать следующий охренительный файл.
Единственное ограничение - размер оперативки. Дело в том, что никогда не предугадаешь, когда винда решит увеличить своп - а по умолчанию у него записан диапазон, а не абсолютный максимальный размер. Также винда видит всю память _примерно_ как некое поле без деления на своп и физическую оперативку. Если ты начинаешь херачить переменные по гигабайту, пол переменной окажется в свопе. И что ты сделаешь тогда?

Найдёшь решение, пиши.