Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2009.05.03;
Скачать: CL | DM;

Вниз

Программа для дефрагментации папки   Найти похожие ветки 

 
Anatoly Podgoretsky ©   (2009-03-01 18:32) [40]

> AndreyV  (01.03.2009 17:25:38)  [38]

Вот именно, что скорость выше и межсерверный промежуток проходит быстрее. Кроме того откуда вывод, что запись последовательная, а не паралельная? Кроме того важен характер операции, последовательное копирование без обработки это одно, а с обработкой другое. Да и система многопользовательская.
То что праильно было в ДОС, часто не применимо в Виндоус, даже то что было правильно скажем в 95, плохо применимо в 98 и в первую очередь с дисковыми операциями.

Ну а метод как в Discreet сейчас не применим к современным дискам. Низкоуровневое форматирование умерло лет 10 назад, теперь нужны другие методы, дающие аналогичный эффект.


 
y3   (2009-03-01 18:50) [41]


> Anatoly Podgoretsky ©   (28.02.09 11:34) [16]


> уже обеспечивают 120 мб/сек по всей поверъности

Нет таких дисков, иначе их называли бы не дисками.
Это говорит о том, что вы привыкли делать один раздел на диск, и он вряд ли полностью заполняется.


> Бороться надо с одновременными вызовами разных файлов в
> разных частях диска, вот это серьезно снижает производительность,
>  а не фрагментация/дефрагментация.

И чем это отличается от ситуации, когда головка чтения/записи вынуждена нестись из начала диска в конец за следующим фрагментом того же файла?


> Очень плохо себя ведут USB диски, блокируется даже интерфейс,
>  как минимум проводник

USB на множественных обращениях дохнут совсем по другой причине. Замер производительности по интерфейсу тоже как бы намекает.

Может не стоит давать советы когда не стоит?


 
blackman ©   (2009-03-01 19:55) [42]

Кто б сомневался ©   (01.03.09 16:49) [37]
Бесплатная. Что же еще требовать...
Но на самом деле, уплотнение и не обязательно.

Очень много написали. И даже есть утверждения того, что дефраг не обязателен. :)  
Для NTFS конечно он не всегда нужен. Вернее долго не нужен, но когда-то его все же приходится делать. Тормоза наступают...
Не думаю, что в Microsoft сидят идиоты и они не зря сделали свой дефрагментатор. Принципы его работы к сожалению не известны.
Работает медленно.
Сравнивал с остальными и понравился только
http://www.auslogics.com/ru/software/disk-defrag
после него уже не нужно запускать виндусовый.


 
Кто б сомневался ©   (2009-03-01 20:29) [43]


> Сравнивал с остальными и понравился только
> http://www.auslogics.com/ru/software/disk-defrag
> после него уже не нужно запускать виндусовый.

для дефрагментации диска мне с головой подходит стандартный. он и уплотняет и делает все качественно .Дефрагментатор от Auslogics плохой.
Он не уплотняет  (картина диска - слишком разреженная, файлы раскиданы везде, по всему диску, зато дефагментированы :) - после него нужно запускать стандартный иначе через некоторое время будет сильная дефрагментация (т.к. новые файлы, будут вставлены в промежуток между файлами) - намного сильнее чем была.
Он делает это быстро за счет того что не делает уплотнение. Короче это большой минус.


 
Кто б сомневался ©   (2009-03-01 20:42) [44]


> Не думаю, что в Microsoft сидят идиоты и они не зря сделали
> свой дефрагментатор

Вот именно. О чем я вам и пытаюсь сказать. Плохо что он не умеет дефрагментировать только выбранные файлы.


 
blackman ©   (2009-03-01 20:45) [45]

Кто б сомневался ©   (01.03.09 20:29) [43]
Не нужно после него ничего запускать. Не факт, что новые не поместятся в промежутки. А если и будут разбиты, то просто запусти его.
Время-то дефрагментации в разы меньше стандартного.
Хочу заметить, что и виндусовый не всегда уплотняет фаловую систему.
Да и уплотнение не всегда поможет. Удали парочку и дыры обеспечены.
А если учесть, что файл подкачки все время изменяется, темпы образуются и удаляются, что-то редактируешь постоянно, то дыры были и будут всегда!
Вот тут и важна скорость дефрага, а не уплотнение.


 
Кто б сомневался ©   (2009-03-01 20:49) [46]

Вот я только что по дурости но для проверки взял и дефрагменитровал папку с играми.
Была - сплошная синяя полоса (в ст. дефр.) а теперь картина такая -
||||| || | | |  | |  |     | | Зато файлы уже не фрагментированы, но блин разбросаны.
Запускаем анализ на ст. дефрагметатрое, пишет что 28 файлов дефрагментировано из это самой папки. Так все таки осталось еще (176 Гб свободно, что ему не хватало)?
Кому доверять Microsoft или той конторе? Я доверяю MS,  а вы сами решайте кому доверять.


 
Кто б сомневался ©   (2009-03-01 20:52) [47]

Время-то дефрагментации в разы меньше стандартного.


> Хочу заметить, что и виндусовый не всегда уплотняет фаловую
> систему.


Всегда. если это необходимо.


> Да и уплотнение не всегда поможет. Удали парочку и дыры
> обеспечены.
> А если учесть, что файл подкачки все время изменяется,


У меня 4 диска не системные. Файл подкачки это мелочь.


> темпы образуются и удаляются, что-то редактируешь постоянно,
>  то дыры были и будут всегда!

Там не такие дыры, как при удалении. вы посмотрите карту диска, там большинство файлов разрбрасываются по диску.
А удаляете вы как правило не большинство.


 
Кто б сомневался ©   (2009-03-01 20:55) [48]

Короче, чтобы не спорить, после дефрагментации прогой этой конторы, посмотрите карту в стандартном дефрагментаторе. Она более объективна.


 
blackman ©   (2009-03-01 21:18) [49]

Кто б сомневался ©   (01.03.09 20:55) [48]
Всегда. если это необходимо
А когда необходимо? Судя по моим дискам эта необходимость возникает редко :)

Зачем спорить? Мы же не знаем, что отображает стандартный.
Особенно ДО дефрагментации. Возможно, что сплошная синяя это в куски порезанные файлы, сплошняком заполняющие эту полосу.
Вы заметили, что на карте нельзя определить расположение конкретного файла?

Мы не можем сравнивать, не знаем эффективности алгоритма MS.
Доверять MS приходится, но жаль потерянного времени.


 
Кто б сомневался ©   (2009-03-01 21:27) [50]


> Зачем спорить? Мы же не знаем, что отображает стандартный.
>
> Особенно ДО дефрагментации. Возможно, что сплошная синяя
> это в куски порезанные файлы, сплошняком заполняющие эту
> полосу.
> Вы заметили, что на карте нельзя определить расположение
> конкретного файла?


В куски порезанные файлы - отображаются красным.

> Вы заметили, что на карте нельзя определить расположение
> конкретного файла?

А на той программе можно? А зачем это вам кстати?

Что означает  цвет полос, подписано внизу, под полосами.

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


 
blackman ©   (2009-03-01 21:58) [51]

Далее, если есть сомнения что стандартный дефрагментатор обманывает пользователя
Почему обманывает? Не всегда отображает :)
А с DiskView надо будет попробовать. Это верно.
Расположение важно, если учитывать частоту обращений и модификации файла.
Повторюсь но, я не считаю бесплатную disk-defrag заранее лучше чем изделия MS, но пользоваться MS слишком утомительно и не всегда это оптимально


 
Mystic ©   (2009-03-01 22:09) [52]


> И чем это отличается от ситуации, когда головка чтения/записи
> вынуждена нестись из начала диска в конец за следующим фрагментом
> того же файла?


Мат. ожидание отличается. Смотри, допустим файл записан последовательно. И читается последовательно. Но из-за буферизации запросы на чтение к винту немного запаздывают. Итого, у нас первая страница файла записана с 45 градусов, до 50, вторая с 50 до 55, третья с 55 до 60 и т. п. Итак

1. Мы читаем страницу файла
2. Головка диска перемещается с 45 до 50 градусов и читает сектор
3. Мы обрабатываем фрагмент (пишем его в буфер и т. п.
4. Головка диска перемещается с 50 гладусов до 52
5. Мы запрашиваем следующий фрагмент. Головка перемещается от 52 до 360 и затем от 0 до 50
6. Головка диска перемещается с 50 до 55 градусов и читает сектор
7. И далее аналогично в цикле

Если представить, что страницы на диске записаны рандомно, то при обращении к следующей странице будет сделан холостой оборот на 180 градусов. Если страницу памяти расположены последовательно, то будет сделан холостой оборот на 360 градусов. А лучше всего, когда страницы файла располагаются через одну, тогда мы получаем холостой оборот 5 градусов.


 
Anatoly Podgoretsky ©   (2009-03-01 23:28) [53]

> y3  (01.03.2009 18:50:41)  [41]

Тем что не надо бежать из начала в конец, так не делается. Так делается для целых файлов, одни файлы в начале, другие в середине, другие в конце, четко видны три группы. Утверждают, что так быстрее, чем писать все в начало.


 
Anatoly Podgoretsky ©   (2009-03-01 23:31) [54]

> blackman  (01.03.2009 19:55:42)  [42]

Ну раз заговорил об МС, то они долго говорили, что на NTFS не требуется, только в последнее добавили его, видимо решили из маркетинговых побуждений. И принципы действительно неизвестны, известно что лицензировано у Norton и наблюдение за ним показывает, что файлы не перемещаются в начала, как у многих, они так и продолжают групироваться кучками.


 
Anatoly Podgoretsky ©   (2009-03-01 23:41) [55]

> blackman  (01.03.2009 21:18:49)  [49]

У меня дефрагментация возникает автоматически, вне желания от ОС, за счет RAID-0 и RAID-10, через каждые 128 кб.


 
blackman ©   (2009-03-02 12:01) [56]

Mystic ©   (01.03.09 22:09) [52]
Это вы про что? Это физика работы, но не чтение файлов. Есть разница и для FAT и NTFS.

Anatoly Podgoretsky ©   (01.03.09 23:31) [54]
что файлы не перемещаются в начала, как у многих, они так и продолжают групироваться кучками.
Для NTFS возможно и нет необходимости их перемещать

NTFS и FAT 32
http://articles.org.ru/cn/showdetail.php?cid=7491
NTFS и FAT: скорость
http://articles.org.ru/cfaq/index.php?qid=1717&catid=20


 
Anatoly Podgoretsky ©   (2009-03-02 12:18) [57]

Про то и речь, но другие дефрагментаторы, ставят это во главу угла.
Вот оттуда вырезки

> NTFS - 3. Фрагментация файлов не влияет на саму файловую
> систему;
> FAT  - 4. Снижение быстродействия при фрагментации;

И все вокруг этого, голый маркетинг.


 
blackman ©   (2009-03-02 12:55) [58]

Anatoly Podgoretsky ©   (02.03.09 12:18) [57]
Все же и для NTFS дефрагментация иногда нужна. Конечно гораздо реже чем для FAT, но нужна


 
Anatoly Podgoretsky ©   (2009-03-02 13:05) [59]

> blackman  (02.03.2009 12:55:58)  [58]

Не столько дефрагментация, сколько фрагментация/дефрагментация MFT


 
y3   (2009-03-02 17:34) [60]


> Если представить, что страницы на диске записаны рандомно,
>  то при обращении к следующей странице будет сделан холостой
> оборот на 180 градусов. Если страницу памяти расположены
> последовательно, то будет сделан холостой оборот на 360
> градусов. А лучше всего, когда страницы файла располагаются
> через одну, тогда мы получаем холостой оборот 5 градусов.
>


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

Я, собственно, возражал высказыванию о том, что дефрагментация вредна. Доказывается без обращений к физике: фрагментация - это процесс (псевдо)случайный, значит он вполне может привести к наихудшему состоянию с точки зрения размещения файлов (так как диск не эдиален - такое состояние есть). Дефрагментация приводит структуру ФС к начальному(оптимальному) состоянию. И в любом случае это уменьшает размер ФС => уменьшает объём ВВ, то есть всё равно выгода. Для NTFS это не так значимо, но всё равно имеет место.


 
Кто б сомневался ©   (2009-03-02 17:42) [61]

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


 
Пробежал   (2009-03-02 17:50) [62]

Я вот не пойму, объясните пожалуйста популярно. если есть ссылки на статью дайте ссылку.

По вашему скорость будет выше если файл будет фрагментирован? Но ведь тогда головке придется каждый раз переключаться, на что требуется время. имхо это очевидно, что если файл идет последовательно, без разрывов, то головка не прыгает в конец и начало диска, а идет последовательно . Соответсвенно ведь и скорость должна быть выше? так ведь?
Ведь файл буферизируется уже после того, как данные будут прочитаны головкой с магнита.


 
Правильный$Вася   (2009-03-02 18:19) [63]


> в Microsoft сидят идиоты и они не зря сделали свой дефрагментатор.
>  Принципы его работы к сожалению не известны.

главное, что к этому всему есть API и бесплатная утилита от Руссиновича, которую уже называли
она и отдельные файлы, и отдельные папки умеет дефрагментировать


 
blackman ©   (2009-03-02 18:47) [64]

Anatoly Podgoretsky ©   (02.03.09 13:05) [59]
Не столько дефрагментация, сколько фрагментация/дефрагментация MFT
Конечно.

Пробежал   (02.03.09 17:50) [62]
Я же привел ссылки в  [56] . Все ясно написано


 
Anatoly Podgoretsky ©   (2009-03-02 19:15) [65]

> Пробежал  (02.03.2009 17:50:02)  [62]

Фрагментация разная бывает, о случайной фрагментации и речи нет, речь о небольшом смещение, что бы времени хватало не небольшую обработку данных, пока диск крутится.


 
Пробежал   (2009-03-02 19:16) [66]


> Пробежал   (02.03.09 17:50) [62]
> Я же привел ссылки в  [56] . Все ясно написано


Где там написано что если файлы фрагментированы, то они быстрее читаются? Там описываются характеристики NTFS и FAT. а здесь на форуме утвержается что из за физ. характеристики (а не из за файловой системы) диска фрагментированые файлы читаются бытрее.


 
Пробежал   (2009-03-02 19:20) [67]


> Anatoly Podgoretsky ©   (02.03.09 19:15) [65]
>
> > Пробежал  (02.03.2009 17:50:02)  [62]
>
> Фрагментация разная бывает, о случайной фрагментации и речи
> нет, речь о небольшом смещение, что бы времени хватало не
> небольшую обработку данных, пока диск крутится.


Опять расплывчатый ответ.
Т.е. получается диск на столько быстро крутится что не успевает считать файл который расположен последовательно?
Так все таки надо дефрагментировать диск или нет? Если нет то объясните толком почему?


 
Anatoly Podgoretsky ©   (2009-03-02 19:23) [68]

> Пробежал  (02.03.2009 19:20:07)  [67]

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


 
clickmaker ©   (2009-03-02 19:25) [69]

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


 
Кто б сомневался ©   (2009-03-02 19:51) [70]


> главное, что к этому всему есть API и бесплатная утилита
> от Руссиновича, которую уже называли
> она и отдельные файлы, и отдельные папки умеет дефрагментировать


не умеет. Она только показывает фрагментацию.


 
blackman ©   (2009-03-02 20:28) [71]

Пробежал   (02.03.09 19:16) [66]
Я не заявлял о том, что фрагментированные будут читаться быстрее.
Говорилось о том, что именно для NTFS, нет особой разницы фрагментированы файлы или нет. Читай [57] и
http://articles.org.ru/cfaq/index.php?qid=1717&catid=20


 
Пробежал   (2009-03-02 21:52) [72]


> NTFS способна обеспечить быстрый поиск фрагментов, поскольку
> вся информация хранится в нескольких очень компактных записях


> Говорилось о том, что именно для NTFS, нет особой разницы
> фрагментированы файлы или нет




Вы не поняли. Мы не говорим о оптимальных алгоритамах поисков фрагментов в файловой системе.  Мы говорим о том, что фрагментацию надо делать (или не делать) для того, чтобы физически головка в hdd совершала меньше лишних движений. Понимаете?
Для NTFS нет разницы, для диска (на аппаратном уровне) есть разница. Вот о чем речь.


 
blackman ©   (2009-03-03 10:25) [73]

Пробежал   (02.03.09 21:52) [72]
Все я понял. Эта физика зависит от файловой системы. Для большого количества дефрагментированных файлов NTFS оптимальнее, а для FAT32 надо постоянно делать дефрагментацию.


 
DrPass ©   (2009-03-03 10:58) [74]


> clickmaker ©   (02.03.09 19:25) [69]
> А при запросах от разных потоков получается, что быстрота
> чтения зависит больше от того, насколько близко в геометрии
> диска будут расположены не фрагменты одного файла, а разных.
>

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


> blackman ©   (03.03.09 10:25) [73]


> Для большого количества дефрагментированных файлов NTFS
> оптимальнее, а для FAT32 надо постоянно делать дефрагментацию.
>

Нет, ни в коем случае. Они одинаково плохо работают при фрагментации файлов. Другое дело, что NTFS устроена таким образом, что минимизирует фрагментацию, пока на диске есть много свободного места.


 
ПРавильный$Вася   (2009-03-03 19:55) [75]


> Кто б сомневался ©   (02.03.09 19:51) [70]

о, да ты еще и читать не умеешь
http://technet.microsoft.com/en-us/sysinternals/bb897428.aspx
Contig is a single-file defragmenter that attempts to make files contiguous on disk. Its perfect for quickly optimizing files that are continuously becoming fragmented, or that you want to ensure are in as few fragments as possible.


 
Кто б сомневался ©   (2009-03-03 20:01) [76]


> > главное, что к этому всему есть API и бесплатная утилита
>
> > от Руссиновича, которую уже называли
> > она и отдельные файлы, и отдельные папки умеет дефрагментировать
>
>
> не умеет. Она только показывает фрагментацию.


> о, да ты еще и читать не умеешь

речь шла о DiskView.


 
Кто б сомневался ©   (2009-03-03 20:02) [77]


> ПРавильный$Вася   (03.03.09 19:55) [75]

Нахамить надо обязательно, иначе ночью не уснешь? :)


 
ПРавильный$Вася   (2009-03-03 20:25) [78]


> > о, да ты еще и читать не умеешь
> речь шла о DiskView.

значит, я прав вдвойне
потому как моя речь шла о Тыщ © (28.02.09 03:53) [10]


 
Кто б сомневался ©   (2009-03-03 20:27) [79]


> значит, я прав вдвойне
> потому как моя речь шла о Тыщ © (28.02.09 03:53) [10]


Молодец, молодец. Возьми пирожок с полки...


 
KilkennyCat ©   (2009-03-03 21:10) [80]

Медленно-быстро... приведите пример задачи, когда фрагментированность так сильно влияет на скорость, что приложения начинают тормозить. Только не теоретическую, такую я и сам могу, а практическую. У меня, например, нет таких задач.
Но я против фрагментированности. Но только не из-за скорости - в последнее время мне крайне не везет с винчестерами. А попробуйте из фрагментированной кучки мусора руками вытащить свои данные...



Страницы: 1 2 3 вся ветка

Текущий архив: 2009.05.03;
Скачать: CL | DM;

Наверх




Память: 0.67 MB
Время: 0.019 c
2-1237207156
madmech
2009-03-16 15:39
2009.05.03
Как рисовать на канве BitBtn?


2-1234167180
AlexDan
2009-02-09 11:13
2009.05.03
Закрытие формы.


2-1237363573
Darvin
2009-03-18 11:06
2009.05.03
Состояние буфера СОМ порта


3-1220351355
Konrads
2008-09-02 14:29
2009.05.03
Самый быстрый запрос


2-1237979966
Alexei
2009-03-25 14:19
2009.05.03
Проблема запуска с помощью ShellExecute