| 1.1, Аноним (-), 07:47, 28/10/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
супер! единственный способ провести дефрагментацию - заново переписать все файлы на разделе. 300 гигов, ага
| | |
| |
| 2.2, Аноним (2), 12:03, 28/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
А что в этом такого?
Ну, неудобно немного, зато сравнительно быстро.
И, кстати, какая разница в производительности EXT3, после такой дефрагментации?
| | |
| |
| 3.3, одмин (?), 13:45, 28/10/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>И, кстати, какая разница в производительности EXT3, после такой дефрагментации?
весьма высокая. Тут дело не в фс а в том что винт физически гораздо лучше справляется с последовательным потоковым чтением чем с random io.
| | |
| |
| 4.4, vitek (??), 15:38, 28/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
это конечно верно. но!
действует либо для больших файлов. либо, например, если программа читает кучу мелких файлов (и довольно быстро читает, например, проигрыватель mp3-шек не подходит), которые расположены рядом. а такого как правило не бывает даже на свеже-созданной фс.
другое дело - винда. там действительно это важно. из-за схемы виртуальной памяти.
там каждый бинарник (dll, exe,...) является свопом сам для себя. из-за этого кстати нельзя например dll-ку удалить, если она загружена в память какой-либо программой, иначе система рухнет. ну и легко представить, что будет, если эти dll-ки разбросаны по всему винту и фрагментированы.
| | |
| |
| 5.5, Аноним (2), 16:37, 28/10/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>ну и легко представить, что будет, если эти dll-ки разбросаны по всему винту и фрагментированы
и что будет?
| | |
| |
| 6.6, vitek (??), 18:47, 28/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>ну и легко представить, что будет, если эти dll-ки разбросаны по всему винту и фрагментированы
>
>и что будет?
тормоза будут.
чем больше живет, чем больше заполнен винт, чем больше с ним проводилось операций удаления/записи, тем медленнее относительно не фрагментированой фс. что часто и наблюдается.
у *nix же зависимость производительности от фрагментации значительно меньше. чаще всего её вообще можно пренебречь. гораздо больше на производительность, например, влияет тюниг журнала в ext3.
| | |
| |
| 7.7, Аноним (-), 21:20, 28/10/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>тормоза будут. чем больше живет, чем больше заполнен винт, чем больше с ним проводилось операций удаления/записи, тем медленнее относительно не фрагментированой фс. что часто и наблюдается.
А причем здесь тогда "схема виртуальной памяти" в винде?
>у *nix же зависимость производительности от фрагментации значительно меньше. чаще всего её вообще можно пренебречь.
А причем здесь тогда "схема виртуальной памяти" в винде?
| | |
| |
| 8.9, vitek (??), 23:20, 28/10/2008 [^] [^^] [^^^] [ответить] | +/– | Не понятно объяснил Повторю КАЖДЫЙ БИНАРНИК под винды сам для себя своп Т е ... текст свёрнут, показать | | |
| |
| 9.10, Аноним (-), 02:17, 29/10/2008 [^] [^^] [^^^] [ответить] | +/– | Структура PE-файлов на диске и в памяти отличается, учите матчасть Т е в выделен... текст свёрнут, показать | | |
| |
| |
| |
| |
| |
| 14.21, vitek (??), 16:37, 29/10/2008 [^] [^^] [^^^] [ответить] | +/– | Вы не только не грамотны и не воспитаны, но ещё и читать не умеете хорошо вот ... текст свёрнут, показать | | |
|
|
| |
| 13.22, Аноним (2), 16:40, 29/10/2008 [^] [^^] [^^^] [ответить] | +/– | Будем Это статья дает очень поверхостное понимание того, как организован VMM,... большой текст свёрнут, показать | | |
| |
| |
| |
| 16.32, vitek (??), 19:34, 29/10/2008 [^] [^^] [^^^] [ответить] | +/– | в который раз уже повторяю, что в линухе через proc и sys можно сделать и не т... текст свёрнут, показать | | |
| |
| |
| 18.41, vitek (??), 07:04, 30/10/2008 [^] [^^] [^^^] [ответить] | +/– | эта функция, NtQuerySystemInformation, только возвращает некоторую информацию о ... текст свёрнут, показать | | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 2.8, User294 (ok), 23:17, 28/10/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>300 гигов, ага
Не хочу ничего сказать но это зачастую весьма быстрый способ дефрагментации сильно засранного и изрядно забитого тома :).Дефрагер не может позволить себе такой роскощи в общем случае и потому обычно вынужден изощренно изгаляться передвигая куски файлов туда-сюда при том на одном физическом девайсе, что вообще-то довольно мееееедленно(при описанном методе в лучшем случае 2 физических девайса будут работать впараллель - с 1го HDD читаем, на 2й временно складываем).На засраном томе много перемещений кусков файлов делается дефрагером вовсе не для того чтобы сделать что-то полезное а просто как служебное действие для расчистки места чтобы можно было выстроить какой-то файл как непрерывный кусок.Если дефрагить дефрагером сильно фрагментированый и забитый том на 300 гиг - это выглядит медленно и печально.
| | |
| |
| 3.11, fix (??), 04:13, 29/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
С одной стороны это так. Но и для Win-разделов можно использовать такой приём, хотя для них давно имеются стабильный штатные дефрагментаторы.
А если под рукой может не оказаться ещё одного винта, равного по объёму? А если винт физически недоступен?
Ну несерьёзно это.
Разумеется, мне могут ответить "возьми и напиши". Готов признаться, что не обладаю ни достаточным опытом и знаниями в этом предмете, ни временем, чтобы взяться за такую серьёзную задачу. Кроме того, необходимо плотное тестирование, что тоже нелегко организовать.
Схема организации виртуальной памяти в win имеет свои преимущества. Скажем, сравните время холодного старта OO и MSO.
| | |
| |
| 4.19, demon (??), 15:44, 29/10/2008 [^] [^^] [^^^] [ответить]
| +/– | |
а-ха-ха !!! товарищ Аноним... вы ещё сошлитесь на сообщения при установке виндов... где пишет, что она самая быстрая и удобная... А уж API виндовое для дефрагментации NTFS было оплёвано и обосранно всеми, кто его имел неосторожность посмотреть... то-то Нортоновский SpeedDisk в обход работал, и умел то, что остальным дефрагментаторам только снилось.
не забывайте, что при заполнении - NTFS начинает резать MFT, а при "выходе из кризиса" потом снова увеличивать... только уже в свободное фрагментированное место... и ничего с этим не поделать...
... и никто давно не замарачивается - просто переустанавливают заново винду и радуются, что она снова быстро работает... а так-то да... MSDN... Балмер...
| | |
| 4.20, User294 (ok), 15:54, 29/10/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>хотя для них давно имеются стабильный штатные дефрагментаторы.
Я попробовал запустить штатный дефраг на засраном NTFS разделе в 40 гиг (всего 40 гиг!!!).Он за 12 часов (ночь) не справился!Это не дефрагер а декоративная бня!Особенно учтя то что файлы эта дребедень не дефрагментирует и пытается только создать непрерывную область свободного места.А как при этом будут раскиданы файлы - этот чудо дефрагер (как минимум в XP и 2003) совершенно не колышет.Если честно то толка с такого дефрагера почти нуль.Ну похрустел он 12 часов головами.И что изменилось?У нортона неплохой дефраг, сравнительно быстрый на не очень засраных дисках.Но глюкастый..... бывало даже разрушение данных оным.
| | |
| |
| 5.25, Аноним (2), 16:58, 29/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Я попробовал запустить штатный дефраг на засраном NTFS разделе в 40 гиг
>(всего 40 гиг!!!).Он за 12 часов (ночь) не справился!Это не дефрагер
>а декоративная бня!Особенно учтя то что файлы эта дребедень не дефрагментирует
>и пытается только создать непрерывную область свободного места.А как при этом
>будут раскиданы файлы - этот чудо дефрагер (как минимум в XP
>и 2003) совершенно не колышет.Если честно то толка с такого дефрагера
>почти нуль.Ну похрустел он 12 часов головами.И что изменилось?У нортона неплохой
>дефраг, сравнительно быстрый на не очень засраных дисках.Но глюкастый..... бывало даже
>разрушение данных оным.
рекомендую PerfectDisk
| | |
| |
| 6.36, User294 (ok), 02:42, 30/10/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>рекомендую PerfectDisk
А он JFS, XFS и EXT3 жрет?Если нет - для меня он на данный момент уже достаточно бесполезный артефакт, потому что от виндов я везде где мог избавился: так мне определенно меньше головняка с майнтенансом систем =).В свое время в винде нортон радовал.Пока не упал при дефраге, оставив некоторое количество файлов основательно испорчеными... гибкость его настроек и скорость работы это конечно хорошо, но вот такой фортель как-то отбил охоту вообще лишний раз юзать дефрагеры :-\.На наиболее засраном томе (250Gb EXT3 забитый на 95%) у мну фрагментация порядка 3%.На виндовых дисках я и 40% видал, а 3% вообще имхо не повод дергаться.
P.S. насчет дефрагов... для истинных мастеров цифровых дел способных размещать файлы так как им захочется есть забавная идея :).Было бы гуд если бы кто-то дотумкал уже оптимизировать LiveCD так чтобы доступ к файлам был более-менее последовательным в ходе загрузки с оного.Для этого вероятно может оказаться достаточно выстроить файлы на исохе в порядке в котором они читаются при загрузке :).Навеяно воспоминаниями о том как CD-ROM натужно гоняет головы туда-сюда при загрузке с ливцд а у сидюков это намного медленнее чем у HDD и там "дефрагментация" (хоть это и не дефрагментация) поактуальнее на пару порядков ;)
| | |
|
| 5.30, fix (??), 19:10, 29/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
>файлы эта дребедень не дефрагментирует и пытается
>только создать непрерывную область свободного места
ерунда. файлы он дефрагментирует
>Ну похрустел он 12 часов головами.И что изменилось?
ускорилась работа OC. заметно даже визуально
>У нортона неплохой дефраг, сравнительно быстрый на не очень засраных дисках.
>Но глюкастый..... бывало даже разрушение данных оным.
здесь все понимают смысл слов "стабильный" и "быстрый"?
P.S. высер demon-а оставлю без внимания
| | |
| |
| 6.35, demon (??), 00:17, 30/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
fix, оставил бы, если б не PSыкал
-----------
проблема дефрагментации NTFS в том, что лучше её не производить вообще, а значит не забивать NTFS раздел более чем на 85%
Если всё-же дефрагментация случилась.. придётся её производить с завидным постоянством, т.к. фрагментирование NTFS после дефрагментации - катастрофически возрастает (уж об этом писано-переписано)
Отсюда и получается, что и для NTFS - копирование пресловутых 300 гигов - наилучший способ...
| | |
| 6.40, User294 (ok), 05:06, 30/10/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>ерунда. файлы он дефрагментирует
Как-то ради интереса гонял дефрагер XP на небольшом разделе (на большом и засраном он работает абсолютно невменяемо по времени) а потом посмотрел что он там нафигачил нортоном(у него карта диска довольно удобная).Налицо была вермишель из файлов - полной дефрагментации дефрагером не было сделано.Свободное место - да, объединено, а файлы остались фрагментированы, может поменьше но уж никак не лежали одним непрерывным блоком.У нортона кстати есть такой режим - для быстрой (и достаточно халтурной) дефрагментации.Еще нортон умеет грамотно оставлять после хвоста файла место на grow файла - иногда разумно даже.
>>Ну похрустел он 12 часов головами.И что изменилось?
>ускорилась работа OC. заметно даже визуально
Ага, черта с два... тот раздел как был тормозной засраной помойкой так и остался таковой.За 12 часов так особо лучше и не стало.Я честно говоря не знаю нахрен такой дефрагер нужен - пахать ему неделю на 40 гиговом разделе никто не даст а если для этого 12 часов мало - тут я пас.
| | |
|
|
| 4.39, User294 (ok), 04:56, 30/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Ну несерьёзно это.
>Разумеется, мне могут ответить "возьми и напиши".
Да вообще где-то болтается скрипт который хоть и немного читерски но дефрагит почти любую ФС - пофайлово.Читерство, ибо не дефраг в привычном понимании но степень фрагментации судя по отзывам снижает (disclaimer: меня фрагментация не допекает и посему лично я это не тестировал).
>Схема организации виртуальной памяти в win имеет свои преимущества. Скажем, сравните время
>холодного старта OO и MSO.
Интересно что вы хотели этим сказать?Кого и где надо сравнивать?А то OO есть под виндовс например.Он и там не больно резво стартует.Или имелось в виду что MSO стартует быстрее потому что использует какие-то недокументированные функции по части управления виртуальной памятью?
| | |
| |
| 5.42, . (?), 11:16, 30/10/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>OO есть под виндовс например.Он и там не больно резво стартует
Резвее, чем в nix. Дело даже не в способах линковки. Просто есть ощутимая разница между "прочитать 200 мегабайт" и "прочитать 200 мегабайт, записать 180 мегабайт" (образно говоря). Да, с мощными камнями и большим объёмом оперативы разница стирается.
Файлы в ntfs дефрагментируются, хоть и не все. Открой диск редактором и посмотри.
| | |
| |
| 6.43, User294 (ok), 09:21, 02/11/2008 [^] [^^] [^^^] [ответить]
| +/– |
>ощутимая разница между "прочитать 200 мегабайт" и "прочитать 200 мегабайт, записать
>180 мегабайт"
То есть, допускается что есть 20 мегов оперативы и в них пытается запихнуться офис?Ну да, круто.Только тормозить будет полюбому - уж не думаете ли вы что 180 мегов выдавятся в своп только для того чтобы никогда больше не прочитаться?А значит такую работу будет 1 хрен сопровождать хруст харда.И подчитаются ли страницы из ехешника или из свопа - в конечном итоге не так важно.Будет медленно и печально.При чтении из кучи файла по всему диску к тому же медленнее и печальнее.Винды вообще своплением раздражают.Если жирную программу 2 часа не трогать и поработать с другой программой - при попытке вернуться в ту программу будут жесточайшие тормоза пока оно там из свопов все подчитает.При том - оно так даже когда оперативка в общем то и не заканчивалась.В результате в винде весьма противно работать с несколькими увесистыми программами например - натужный хруст харда и тормознутый отклик программ гарантирован.Линуксы этим не страдают - они лезут в своп только когда натурально приперло.
| | |
|
|
|
|
|
|
