"Tuning the Linux file system Ext3 (http://www.heise-online.co.uk/open/Tuning-the-Linux-file-sys...)" - подробное руководство по тюнингу файловой системы Ext3. Среди прочего рассмотрены вопросы фрагментации данных, затронута тема изменения производительности в зависимости (http://www.heise-online.co.uk/images/110398/2/1) от объема памяти в системе, интенсивности файловых операций и числа файлов в директории.URL: http://www.heise-online.co.uk/open/Tuning-the-Linux-file-sys...
Новость: http://www.opennet.me/opennews/art.shtml?num=18597
супер! единственный способ провести дефрагментацию - заново переписать все файлы на разделе. 300 гигов, ага
А что в этом такого?
Ну, неудобно немного, зато сравнительно быстро.И, кстати, какая разница в производительности EXT3, после такой дефрагментации?
>И, кстати, какая разница в производительности EXT3, после такой дефрагментации?весьма высокая. Тут дело не в фс а в том что винт физически гораздо лучше справляется с последовательным потоковым чтением чем с random io.
это конечно верно. но!
действует либо для больших файлов. либо, например, если программа читает кучу мелких файлов (и довольно быстро читает, например, проигрыватель mp3-шек не подходит), которые расположены рядом. а такого как правило не бывает даже на свеже-созданной фс.другое дело - винда. там действительно это важно. из-за схемы виртуальной памяти.
там каждый бинарник (dll, exe,...) является свопом сам для себя. из-за этого кстати нельзя например dll-ку удалить, если она загружена в память какой-либо программой, иначе система рухнет. ну и легко представить, что будет, если эти dll-ки разбросаны по всему винту и фрагментированы.
>ну и легко представить, что будет, если эти dll-ки разбросаны по всему винту и фрагментированыи что будет?
>>ну и легко представить, что будет, если эти dll-ки разбросаны по всему винту и фрагментированы
>
>и что будет?тормоза будут.
чем больше живет, чем больше заполнен винт, чем больше с ним проводилось операций удаления/записи, тем медленнее относительно не фрагментированой фс. что часто и наблюдается.
у *nix же зависимость производительности от фрагментации значительно меньше. чаще всего её вообще можно пренебречь. гораздо больше на производительность, например, влияет тюниг журнала в ext3.
>тормоза будут. чем больше живет, чем больше заполнен винт, чем больше с ним проводилось операций удаления/записи, тем медленнее относительно не фрагментированой фс. что часто и наблюдается.А причем здесь тогда "схема виртуальной памяти" в винде?
>у *nix же зависимость производительности от фрагментации значительно меньше. чаще всего её вообще можно пренебречь.
А причем здесь тогда "схема виртуальной памяти" в винде?
>А причем здесь тогда "схема виртуальной памяти" в винде?Не понятно объяснил? Повторю!
КАЖДЫЙ БИНАРНИК под винды сам для себя своп. Т.е. если нужно сбросить или вытащить страничку ОЗУ из/в свопа, то она будет тащиться из/в того места на диске, где размазан этот бинарник. Например, файл состоит из 5 секторов, при чём первый в 3487, второй - в 11, 3 - в 12324354, 4 - в 47, 5 - в 903424.
ОЧЕНЬ много перемещений головки!!! И чем "старше" фс, тем эта ситуация всё более реальней и тем медленнее.
Вывод - без периодической дефрагментации никуда.
>А причем здесь тогда "схема виртуальной памяти" в винде?При том, что для винды фрагментация ОЧЕНЬ важна, а для *nix - нет.
Хотя не важно! На Вас только время терять...
>КАЖДЫЙ БИНАРНИК под винды сам для себя своп.Структура PE-файлов на диске и в памяти отличается, учите матчасть
>Т.е. если нужно сбросить или вытащить страничку ОЗУ из/в свопа, то она будет тащиться из/в того места на диске, где размазан этот бинарник.
Т.е в выделенном своп-файле, по вашему, хранятся совершенно левые данные, а не неактивные страницы памяти? Ну-ну...
>При том, что для винды фрагментация ОЧЕНЬ важна, а для *nix - нет.
При фрагментаци FS что в линуксе, что в винде, да и в любой ОС - будут тормоза.
Только непонятно, чем среди всего этого отличилась "схема виртуальной памяти" в винде? :D
>Структура PE-файлов на диске и в памяти отличается, учите матчастьну отличается и что? учите матчасть
>Т.е в выделенном своп-файле, по вашему, хранятся совершенно левые данные, а не
>неактивные страницы памяти? Ну-ну...Не "левые"... Но и не код... И именно из-за сируктуры виртуальной памяти... учите матчасть
>При фрагментаци FS что в линуксе, что в винде, да и в
>любой ОС - будут тормоза.
>
>Только непонятно, чем среди всего этого отличилась "схема виртуальной памяти" в винде?
>:Dучите матчасть.
>ну отличается и что?Т.е. "сам себе своп" - это вы сами придумали или какой-то кулхацкер подсказал? По возможности, поделитесь соответствующей ссылкой на rsdn/msdn/wasm.ru (прозреваю, что вы, за неимением таковых, пошлете меня в гугл - тогда защитаем ваш слив :)
>Не "левые"... Но и не код...
ЛОЛ! А что же тогда? :D Поделитесь источником вашей информации!
>учите матчасть
Это вы её подучите, чтобы бреда собачьего вроде "сам себе своп" больше не писать, уважаемый :D
ссылки, уважаемый, известны - msdn, google,.... и учебные заведения.
и я бы ими поделился, но Ваш тон отбивает всякое желание к подобным действиям.
>Это вы её подучите, чтобы бреда собачьего вроде "сам себе своп" больше не писать, уважаемый :DВам ещё очень многому нужно учиться.
>ссылки, уважаемый, известны - msdn, google,.... и учебные заведения.Слив защитан! :D
>Слив защитан! :DКому?Винды насколько я помню натурально могут отбрасывать страницы без слива их в своп, подчитывая их из образа PE EXE с диска при необходимости вместо того чтобы соваться в своп.Это в свое время было сделано чтобы снизить интенсивность использования свопа (экономия на отсутствии операции записи).Насколько я помню это один из аргументов против интенсивного юзания EXE-пакеров - если EXE сжат, системе ничего не останется кроме как выдавливать его в своп, потому что подчитать страницу из сжатого образа EXE файла не выйдет.Логично что фрагментация EXE по диску при этом ни к чему хорошему не приведет.
Вы не только не грамотны и не воспитаны, но ещё и читать не умеете.
хорошо. вот Вам и ещё ссылка:
http://www.helloworld.ru/texts/comp/lang/visualc/vc/THEORY/H...
Однако файл подкачки ґ не единственный файл, используемый диспетчером виртуальной памяти. Нет особого смысла в том, чтобы записывать в этот файл страницы кода. Вместо этого Windows проецирует ЕХЕ- и DLL-модули непосредственно на их дисковые файлы. Поскольку страницы кода помечены как "только для чтения", то необходимости в их записи обратно на диск не возникает. Если два процесса используют один и тот же ЕХЕ-файл, то данный файл отображается на адресные пространства обоих процессов. Файлы, проецируемые в память, о которых мы поговорим позже, также отображаются напрямую. Они доступны "для чтения и записи" и разделяются несколькими процессами.
>вот Вам и ещё ссылка:
>http://www.helloworld.ru/texts/comp/lang/visualc/vc/THEORY/H...
>Однако файл подкачки ґ не единственный файл, используемый диспетчером виртуальной памяти. Нет особого смысла в том, чтобы записывать в этот файл страницы кода. Вместо этого Windows проецирует ЕХЕ- и DLL-модули непосредственно на их дисковые файлы.Не совсем верно, т.к. Windows проецирует лишь те и только те секции, которые помечены ка read-only и немодифицируемые. Автоматом целый файл никуда не проецируется, т.к. могут быть bss-секции, к примеру
>Не совсем верно, т.к. Windows проецирует лишь те и только те секции,
>которые помечены ка read-only и немодифицируемые. Автоматом целый файл никуда не
>проецируется, т.к. могут быть bss-секции, к примеруа вот это верно!
Но! разговор то шёл в рамках топика.
Да и разница какая?... Особенно если в сильно нагруженной, забитой файлами (сразу вспоминаются терминальные сервера) и ОЧЕНЬ сильно фрагментированной среде?... Можно говорить, что свопом является весь диск?... Да и странички качаются случайным образом?.
хотя.... будем считать, что Вы не всегда хам....
http://citforum.yspu.yar.ru/operating_systems/solaris/unix.s...
Область памяти, занятая программой разделена на три части: TEXT (выполняемые коды программы), DATA (статические данные программы), STACK (динамические данные). Когда операционка освобождает место в памяти за счет TEXT'а, то она не занимается сбросом его на диск. Она сразу помечает его как свободный. Действительно, когда потребуется загрузить TEXT обратно в память, его можно будет взять из самого выполняемого файла с программой. Такая экономия имеет один побочный эффект. Файл программы, которая в данный момент выполняется, невозможно уничтожить. Операционная система сообщит в этом случае: "text file busy", и откажется выполнять удаление.похоже ведет себя и windows. вернее она только так и умеет.
и при такой работе фрагментация на диске ОЧЕНЬ сильно влияет на производительность.
в линухе (при его штатной настройке - 99,9%) на эту фрагментацию можно не обращать внимания вообще, т.к. проще и лучше настроить журнал и кэшь, которые этот аффект уберут.
>хотя.... будем считать, что Вы не всегда хам....Будем :)
>http://citforum.yspu.yar.ru/operating_systems/solaris/unix.s...
Это статья дает очень поверхостное понимание того, как организован VMM, даже в unix, не говоря уже о винде. поэтому рекомендую к прочтению http://www.elinux.ru/arhitec/arg_1.php, если осилите. А далее по пунктам:
>Область памяти, занятая программой разделена на три части: TEXT (выполняемые коды программы), DATA (статические данные программы), STACK (динамические данные).
А как же BSS, RODATA и пр.?
>Когда операционка освобождает место в памяти за счет TEXT'а, то она не занимается сбросом его на диск. Она сразу помечает его как свободный.
Т.е. мы свопимся ради свободной ОЗУ? Забавно :)
>Действительно, когда потребуется загрузить TEXT обратно в память, его можно будет взять из самого выполняемого файла с программой.
Ну да, и тут фрагментация - как раз кстати, на ЛЮБОЙ ОС :)
>Такая экономия имеет один побочный эффект. Файл программы, которая в данный момент выполняется, невозможно уничтожить. Операционная система сообщит в этом случае: "text file busy", и откажется выполнять удаление.
А я под рутом в линуксе взял и удалил - значит кто-то из нас двоих глубоко заблуждается или просто не понимает то, о чем говорит
>похоже ведет себя и windows. вернее она только так и умеет.
Странно, а выше вы утверждали, что VMM в винде какой-то особенный, а тут уже "похоже" )
>и при такой работе фрагментация на диске ОЧЕНЬ сильно влияет на производительность.
Как я уже утверждал - на любой ОС
>в линухе (при его штатной настройке - 99,9%) на эту фрагментацию можно не обращать внимания вообще, т.к. проще и лучше настроить журнал и кэшь, которые этот аффект уберут.Вы хоть подберите нормальные аргументы, а то в начале поста говорите одно, а в конце - какой-то откровенный бред несете, с элементами НЛП
Но для вас я все-же расскажу то, как все есть на самом деле.
Представим себе систему без файла подкачки. Для ОС существует набор страниц RAM (для PC - 4К). Состояние у каждой страницы всего два: занята и свободна. При запуске программы часть ее считивается с диска, т.е. попадает в дисковый кеш, который всегда находится в свободной памяти. Затем ядром системы формируется виртуальное пространство процесса, данные и код из дискового кеша копируются в свободные страницы (которые помечаются как занятые), там выравниваются по секциям и пр. и программа начинает работать, к примеру. Я не зря упомянул про дисковые буферы: они находятся в _свободной_ памяти и содержат кешированные данные _с диска_, т.е. при больших запросах памяти нашим приложением будут оттуда стерты, т.е. закрыв приложение, а затем попытавшись его снова запустить, ОС, если нет свободной памяти (т.е. нет дискового кеша) будет вынуждена заново прочитать файл, т.к. (повторяю) бинарники в фале и бинарники в ОЗУ отличаются! Так дела обстоят и в windows, и в linux. Разница же между linux и windows в том, что последняя позволяет задать минимальный и максимальный размеры дискового буфера, а в линуксе просто верхний порог всегда на максимуме - и у некоторых (как у вас, например) это вызывает ложные ощущения о якобы существенных различиях в VMM (угу, это на одной платформе, с одной и той же логикой MMU :D). С файлом подкачки ситуация не сильно меняется: дисковый кеш остается в физической ОЗУ (сколько там ее свободно). Все. Желаю успехов в изучении матчасти!
много написано... и глупо... читайте комментарий выше.
>Состояние у каждой страницы всего два: занята и свободна.научитесь хоть msdn-ом пользоваться http://msdn.microsoft.com/en-us/library/ms810616.aspx
... the status of every physical page of memory in the system... Valid, Modified, Standby, Free, Zeroed, Bad
а вот это вообще не правда, если не сказать больше:
>Так дела обстоят и в windows, и в linux. Разница же между linux и windows в том, что последняя позволяет задать минимальный и максимальный размеры дискового буфера, а в линуксе просто верхний порог всегда на максимуме - и у некоторых (как у вас, например) ...начните отсюда: http://en.wikipedia.org/wiki/Virtual_memory , а то по-моему у Вас все смешалось в голове... как у студента перед сессией... и тем более после.
>Valid, Modified, Standby, Free, Zeroed, BadВad не рассматриваем в нашем случае; valid, modified это значит занята, free и standby значит свободна ___если смотреть "глазами" ОС, когда какой-то процесс требует выделить ему память___. Zeroed это общем случае тоже не рассматривается.
>а вот это вообще не правда
>а то по-моему у Вас все смешалось в голове... как у студента перед сессией... и тем более после.Да это вы можете сколько угодно фантазировать :D Вот непонятно только, что в "схеме виртуальной памяти" винды такого, что из-за фрагментации FS в винде загрузка приложений тормозит, а в линуксе - нет??? Я услышал от вас, что есть "схожесть", но не услышал и не увидел ссылок на кардинальные _отличия VMM_ - собственно, это единственное, что мне нужно. Также впечатлает объем вашего комментария на мой достаточно большой пост - что явно говорит об уровне вашей подготовки :)
>Да это вы можете сколько угодно фантазировать :D Вот непонятно только, что в "схеме виртуальной памяти" винды такого, что из-за фрагментации FS в винде загрузка приложений тормозит, а в линуксе - нет??? Я услышал от вас, что есть "схожесть", но не услышалсамый первый мой комментарий. в windows нельзя удалить dll, exe,... которые сейчас запущены на выполнение, а в linux я запросто произвожу update ПО, которое сейчас работает.
Не понятно почему?
>Также впечатлает объем вашего комментария на мой достаточно большой пост - что явно говорит об уровне вашей подготовки :):-DDDDDD
А с чего Вы взяли, что я должен Вам что-то развёрнуто доказывать?
Да и на Ваше мнение о моей компетенции меня мало волнует... Тем более, что Ваш уровень я уже видел.
>а вот это вообще не правда, если не сказать большеГраницы дискового буфера в винде можно задать с помощю функции NtQuerySystemInformation c параметром SYSTEMCACHEINFORMATION. В который раз повторю: учите матчасть.
>Границы дискового буфера в винде можно задать с помощю функции NtQuerySystemInformation c
>параметром SYSTEMCACHEINFORMATION. В который раз повторю: учите матчасть.в который раз уже повторяю, что в линухе через /proc и /sys можно сделать и не такое.
но это к разговору не имеет НИКАКОГО отношения....Когда Вы объясните, почему запущенное на выполнение ПО под линух можно проапдейтить/удалить/..., а под винды - нет и как это связано с виртуальной памятью и фрагментацией на диске, тогда и появится у Вас право давать кому-нибудь советы.
А пока что... учите матчасть. :-DDDDDDDDDDDDDDDDDDDDDDD
(а то в комменте 10 Вы вообще утверждали, что в виндах бинарник свопиться,.. хорошо хоть одумались под конец)
>Границы дискового буфера в винде можно задать с помощю функции NtQuerySystemInformation c
>параметром SYSTEMCACHEINFORMATION. В который раз повторю: учите матчасть.А выполняется она от рута? пьху!!! админа?
Или каждый желающий?
А то было бы забавно;-)
>А выполняется она от рута? пьху!!! админа?Мде, попробовал документацию на эту функцию почитать... как вам такое описание? http://msdn.microsoft.com/en-us/library/ms724509(VS.85).aspx
Такое ощущение что писал его почтальон Печкин - дескать, посылка у меня есть но вам я ее не отдам.Описание явно писалось по этому же принципу :)
эта функция, NtQuerySystemInformation, только возвращает некоторую информацию о системе, а не изменяет её.
и из названия это следует.
но к разговору это не относится. :-)
Windows никогда не свопирует выполняемый код, т.к. априори предполагает, что
а) он неизменяем
б) его всегда без проблем можно заново считать из запускаемого файла
(кстати именно поэтому при использовании пакеров exe-файлов Windows приходится свопить весь распакованый exe-файл в своп).Свопируются только данные! Поэтому все ваши наезды вообще говоря не понятны.
>Windows никогда не свопирует выполняемый код, т.к. априори предполагает, что
>а) он неизменяем
>б) его всегда без проблем можно заново считать из запускаемого файла
>(кстати именно поэтому при использовании пакеров exe-файлов Windows приходится свопить весь распакованый
>exe-файл в своп).
>
>Свопируются только данные! Поэтому все ваши наезды вообще говоря не понятны.И вам повторю: свопирутся секции, согласно флагам, и никаких "априори"
>И вам повторю: свопирутся секции, согласно флагам, и никаких "априори"Без разницы весь файл или его части.
Важен результат.
А он известен - переустановка винды. И диск желательно переразбить.
>И вам повторю: свопирутся секции, согласно флагам, и никаких "априори"Если дефолты рассмотреть и как оно обычно происходит без всякой экзотики - как раз обычно получается размазанный по всему диску "своп" потому что система зачастую подчитывает страницы из EXE файлов а не из свопа.И априори, по дефолту, в поставке винды ехешники сделаны именно так, насколько я знаю.
У вас есть что-то возразить по делу и вам есть чем оспорить тот факт что фрагментация в этом случае все усугубляет?Или вы так, софистикой занимаетесь чтобы отмыться от какашек которые в вас полетели?
>300 гигов, агаНе хочу ничего сказать но это зачастую весьма быстрый способ дефрагментации сильно засранного и изрядно забитого тома :).Дефрагер не может позволить себе такой роскощи в общем случае и потому обычно вынужден изощренно изгаляться передвигая куски файлов туда-сюда при том на одном физическом девайсе, что вообще-то довольно мееееедленно(при описанном методе в лучшем случае 2 физических девайса будут работать впараллель - с 1го HDD читаем, на 2й временно складываем).На засраном томе много перемещений кусков файлов делается дефрагером вовсе не для того чтобы сделать что-то полезное а просто как служебное действие для расчистки места чтобы можно было выстроить какой-то файл как непрерывный кусок.Если дефрагить дефрагером сильно фрагментированый и забитый том на 300 гиг - это выглядит медленно и печально.
С одной стороны это так. Но и для Win-разделов можно использовать такой приём, хотя для них давно имеются стабильный штатные дефрагментаторы.
А если под рукой может не оказаться ещё одного винта, равного по объёму? А если винт физически недоступен?
Ну несерьёзно это.
Разумеется, мне могут ответить "возьми и напиши". Готов признаться, что не обладаю ни достаточным опытом и знаниями в этом предмете, ни временем, чтобы взяться за такую серьёзную задачу. Кроме того, необходимо плотное тестирование, что тоже нелегко организовать.Схема организации виртуальной памяти в win имеет свои преимущества. Скажем, сравните время холодного старта OO и MSO.
а-ха-ха !!! товарищ Аноним... вы ещё сошлитесь на сообщения при установке виндов... где пишет, что она самая быстрая и удобная... А уж API виндовое для дефрагментации NTFS было оплёвано и обосранно всеми, кто его имел неосторожность посмотреть... то-то Нортоновский SpeedDisk в обход работал, и умел то, что остальным дефрагментаторам только снилось.не забывайте, что при заполнении - NTFS начинает резать MFT, а при "выходе из кризиса" потом снова увеличивать... только уже в свободное фрагментированное место... и ничего с этим не поделать...
... и никто давно не замарачивается - просто переустанавливают заново винду и радуются, что она снова быстро работает... а так-то да... MSDN... Балмер...
>хотя для них давно имеются стабильный штатные дефрагментаторы.Я попробовал запустить штатный дефраг на засраном NTFS разделе в 40 гиг (всего 40 гиг!!!).Он за 12 часов (ночь) не справился!Это не дефрагер а декоративная бня!Особенно учтя то что файлы эта дребедень не дефрагментирует и пытается только создать непрерывную область свободного места.А как при этом будут раскиданы файлы - этот чудо дефрагер (как минимум в XP и 2003) совершенно не колышет.Если честно то толка с такого дефрагера почти нуль.Ну похрустел он 12 часов головами.И что изменилось?У нортона неплохой дефраг, сравнительно быстрый на не очень засраных дисках.Но глюкастый..... бывало даже разрушение данных оным.
>Я попробовал запустить штатный дефраг на засраном NTFS разделе в 40 гиг
>(всего 40 гиг!!!).Он за 12 часов (ночь) не справился!Это не дефрагер
>а декоративная бня!Особенно учтя то что файлы эта дребедень не дефрагментирует
>и пытается только создать непрерывную область свободного места.А как при этом
>будут раскиданы файлы - этот чудо дефрагер (как минимум в XP
>и 2003) совершенно не колышет.Если честно то толка с такого дефрагера
>почти нуль.Ну похрустел он 12 часов головами.И что изменилось?У нортона неплохой
>дефраг, сравнительно быстрый на не очень засраных дисках.Но глюкастый..... бывало даже
>разрушение данных оным.рекомендую PerfectDisk
>рекомендую PerfectDiskА он JFS, XFS и EXT3 жрет?Если нет - для меня он на данный момент уже достаточно бесполезный артефакт, потому что от виндов я везде где мог избавился: так мне определенно меньше головняка с майнтенансом систем =).В свое время в винде нортон радовал.Пока не упал при дефраге, оставив некоторое количество файлов основательно испорчеными... гибкость его настроек и скорость работы это конечно хорошо, но вот такой фортель как-то отбил охоту вообще лишний раз юзать дефрагеры :-\.На наиболее засраном томе (250Gb EXT3 забитый на 95%) у мну фрагментация порядка 3%.На виндовых дисках я и 40% видал, а 3% вообще имхо не повод дергаться.
P.S. насчет дефрагов... для истинных мастеров цифровых дел способных размещать файлы так как им захочется есть забавная идея :).Было бы гуд если бы кто-то дотумкал уже оптимизировать LiveCD так чтобы доступ к файлам был более-менее последовательным в ходе загрузки с оного.Для этого вероятно может оказаться достаточно выстроить файлы на исохе в порядке в котором они читаются при загрузке :).Навеяно воспоминаниями о том как CD-ROM натужно гоняет головы туда-сюда при загрузке с ливцд а у сидюков это намного медленнее чем у HDD и там "дефрагментация" (хоть это и не дефрагментация) поактуальнее на пару порядков ;)
>файлы эта дребедень не дефрагментирует и пытается
>только создать непрерывную область свободного местаерунда. файлы он дефрагментирует
>Ну похрустел он 12 часов головами.И что изменилось?ускорилась работа OC. заметно даже визуально
>У нортона неплохой дефраг, сравнительно быстрый на не очень засраных дисках.
>Но глюкастый..... бывало даже разрушение данных оным.здесь все понимают смысл слов "стабильный" и "быстрый"?
P.S. высер demon-а оставлю без внимания
fix, оставил бы, если б не PSыкал
-----------
проблема дефрагментации NTFS в том, что лучше её не производить вообще, а значит не забивать NTFS раздел более чем на 85%
Если всё-же дефрагментация случилась.. придётся её производить с завидным постоянством, т.к. фрагментирование NTFS после дефрагментации - катастрофически возрастает (уж об этом писано-переписано)
Отсюда и получается, что и для NTFS - копирование пресловутых 300 гигов - наилучший способ...
>ерунда. файлы он дефрагментируетКак-то ради интереса гонял дефрагер XP на небольшом разделе (на большом и засраном он работает абсолютно невменяемо по времени) а потом посмотрел что он там нафигачил нортоном(у него карта диска довольно удобная).Налицо была вермишель из файлов - полной дефрагментации дефрагером не было сделано.Свободное место - да, объединено, а файлы остались фрагментированы, может поменьше но уж никак не лежали одним непрерывным блоком.У нортона кстати есть такой режим - для быстрой (и достаточно халтурной) дефрагментации.Еще нортон умеет грамотно оставлять после хвоста файла место на grow файла - иногда разумно даже.
>>Ну похрустел он 12 часов головами.И что изменилось?
>ускорилась работа OC. заметно даже визуальноАга, черта с два... тот раздел как был тормозной засраной помойкой так и остался таковой.За 12 часов так особо лучше и не стало.Я честно говоря не знаю нахрен такой дефрагер нужен - пахать ему неделю на 40 гиговом разделе никто не даст а если для этого 12 часов мало - тут я пас.
>Ну несерьёзно это.
>Разумеется, мне могут ответить "возьми и напиши".Да вообще где-то болтается скрипт который хоть и немного читерски но дефрагит почти любую ФС - пофайлово.Читерство, ибо не дефраг в привычном понимании но степень фрагментации судя по отзывам снижает (disclaimer: меня фрагментация не допекает и посему лично я это не тестировал).
>Схема организации виртуальной памяти в win имеет свои преимущества. Скажем, сравните время
>холодного старта OO и MSO.Интересно что вы хотели этим сказать?Кого и где надо сравнивать?А то OO есть под виндовс например.Он и там не больно резво стартует.Или имелось в виду что MSO стартует быстрее потому что использует какие-то недокументированные функции по части управления виртуальной памятью?
>OO есть под виндовс например.Он и там не больно резво стартуетРезвее, чем в nix. Дело даже не в способах линковки. Просто есть ощутимая разница между "прочитать 200 мегабайт" и "прочитать 200 мегабайт, записать 180 мегабайт" (образно говоря). Да, с мощными камнями и большим объёмом оперативы разница стирается.
Файлы в ntfs дефрагментируются, хоть и не все. Открой диск редактором и посмотри.
>ощутимая разница между "прочитать 200 мегабайт" и "прочитать 200 мегабайт, записать
>180 мегабайт"То есть, допускается что есть 20 мегов оперативы и в них пытается запихнуться офис?Ну да, круто.Только тормозить будет полюбому - уж не думаете ли вы что 180 мегов выдавятся в своп только для того чтобы никогда больше не прочитаться?А значит такую работу будет 1 хрен сопровождать хруст харда.И подчитаются ли страницы из ехешника или из свопа - в конечном итоге не так важно.Будет медленно и печально.При чтении из кучи файла по всему диску к тому же медленнее и печальнее.Винды вообще своплением раздражают.Если жирную программу 2 часа не трогать и поработать с другой программой - при попытке вернуться в ту программу будут жесточайшие тормоза пока оно там из свопов все подчитает.При том - оно так даже когда оперативка в общем то и не заканчивалась.В результате в винде весьма противно работать с несколькими увесистыми программами например - натужный хруст харда и тормознутый отклик программ гарантирован.Линуксы этим не страдают - они лезут в своп только когда натурально приперло.