форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[ Отслеживать ]

"Подробное руководство по тюнингу файловой системы Ext3"

Сообщение от opennews (??) on 28-Окт-08, 07:47

"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

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Подробное руководство по тюнингу файловой системы Ext3"

Сообщение от Аноним (??) on 28-Окт-08, 07:47

супер! единственный способ провести дефрагментацию - заново переписать все файлы на разделе. 300 гигов, ага

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 28-Окт-08, 12:03
	А что в этом такого? Ну, неудобно немного, зато сравнительно быстро. И, кстати, какая разница в производительности EXT3, после такой дефрагментации?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от одмин on 28-Окт-08, 13:45
	>И, кстати, какая разница в производительности EXT3, после такой дефрагментации? весьма высокая. Тут дело не в фс а в том что винт физически гораздо лучше справляется с последовательным потоковым чтением чем с random io.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 28-Окт-08, 15:38
	это конечно верно. но! действует либо для больших файлов. либо, например, если программа читает кучу мелких файлов (и довольно быстро читает, например, проигрыватель mp3-шек не подходит), которые расположены рядом. а такого как правило не бывает даже на свеже-созданной фс. другое дело - винда. там действительно это важно. из-за схемы виртуальной памяти. там каждый бинарник (dll, exe,...) является свопом сам для себя. из-за этого кстати нельзя например dll-ку удалить, если она загружена в память какой-либо программой, иначе система рухнет. ну и легко представить, что будет, если эти dll-ки разбросаны по всему винту и фрагментированы.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 28-Окт-08, 16:37
	>ну и легко представить, что будет, если эти dll-ки разбросаны по всему винту и фрагментированы и что будет?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 28-Окт-08, 18:47
	>>ну и легко представить, что будет, если эти dll-ки разбросаны по всему винту и фрагментированы > >и что будет? тормоза будут. чем больше живет, чем больше заполнен винт, чем больше с ним проводилось операций удаления/записи, тем медленнее относительно не фрагментированой фс. что часто и наблюдается. у *nix же зависимость производительности от фрагментации значительно меньше. чаще всего её вообще можно пренебречь. гораздо больше на производительность, например, влияет тюниг журнала в ext3.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 28-Окт-08, 21:20
	>тормоза будут. чем больше живет, чем больше заполнен винт, чем больше с ним проводилось операций удаления/записи, тем медленнее относительно не фрагментированой фс. что часто и наблюдается. А причем здесь тогда "схема виртуальной памяти" в винде? >у *nix же зависимость производительности от фрагментации значительно меньше. чаще всего её вообще можно пренебречь. А причем здесь тогда "схема виртуальной памяти" в винде?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 28-Окт-08, 23:20
	>А причем здесь тогда "схема виртуальной памяти" в винде? Не понятно объяснил? Повторю! КАЖДЫЙ БИНАРНИК под винды сам для себя своп. Т.е. если нужно сбросить или вытащить страничку ОЗУ из/в свопа, то она будет тащиться из/в того места на диске, где размазан этот бинарник. Например, файл состоит из 5 секторов, при чём первый в 3487, второй - в 11, 3 - в 12324354, 4 - в 47, 5 - в 903424. ОЧЕНЬ много перемещений головки!!! И чем "старше" фс, тем эта ситуация всё более реальней и тем медленнее. Вывод - без периодической дефрагментации никуда. >А причем здесь тогда "схема виртуальной памяти" в винде? При том, что для винды фрагментация ОЧЕНЬ важна, а для *nix - нет. Хотя не важно! На Вас только время терять...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 29-Окт-08, 02:17
	>КАЖДЫЙ БИНАРНИК под винды сам для себя своп. Структура PE-файлов на диске и в памяти отличается, учите матчасть >Т.е. если нужно сбросить или вытащить страничку ОЗУ из/в свопа, то она будет тащиться из/в того места на диске, где размазан этот бинарник. Т.е в выделенном своп-файле, по вашему, хранятся совершенно левые данные, а не неактивные страницы памяти? Ну-ну... >При том, что для винды фрагментация ОЧЕНЬ важна, а для *nix - нет. При фрагментаци FS что в линуксе, что в винде, да и в любой ОС - будут тормоза. Только непонятно, чем среди всего этого отличилась "схема виртуальной памяти" в винде? :D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 29-Окт-08, 10:07
	>Структура PE-файлов на диске и в памяти отличается, учите матчасть ну отличается и что? учите матчасть >Т.е в выделенном своп-файле, по вашему, хранятся совершенно левые данные, а не >неактивные страницы памяти? Ну-ну... Не "левые"... Но и не код... И именно из-за сируктуры виртуальной памяти... учите матчасть >При фрагментаци FS что в линуксе, что в винде, да и в >любой ОС - будут тормоза. > >Только непонятно, чем среди всего этого отличилась "схема виртуальной памяти" в винде? >:D учите матчасть.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 29-Окт-08, 10:30
	>ну отличается и что? Т.е. "сам себе своп" - это вы сами придумали или какой-то кулхацкер подсказал? По возможности, поделитесь соответствующей ссылкой на rsdn/msdn/wasm.ru (прозреваю, что вы, за неимением таковых, пошлете меня в гугл - тогда защитаем ваш слив :) >Не "левые"... Но и не код... ЛОЛ! А что же тогда? :D Поделитесь источником вашей информации! >учите матчасть Это вы её подучите, чтобы бреда собачьего вроде "сам себе своп" больше не писать, уважаемый :D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 29-Окт-08, 13:40
	ссылки, уважаемый, известны - msdn, google,.... и учебные заведения. и я бы ими поделился, но Ваш тон отбивает всякое желание к подобным действиям. >Это вы её подучите, чтобы бреда собачьего вроде "сам себе своп" больше не писать, уважаемый :D Вам ещё очень многому нужно учиться.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 29-Окт-08, 15:24
	>ссылки, уважаемый, известны - msdn, google,.... и учебные заведения. Слив защитан! :D
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от User294 (ok) on 29-Окт-08, 15:43
	>Слив защитан! :D Кому?Винды насколько я помню натурально могут отбрасывать страницы без слива их в своп, подчитывая их из образа PE EXE с диска при необходимости вместо того чтобы соваться в своп.Это в свое время было сделано чтобы снизить интенсивность использования свопа (экономия на отсутствии операции записи).Насколько я помню это один из аргументов против интенсивного юзания EXE-пакеров - если EXE сжат, системе ничего не останется кроме как выдавливать его в своп, потому что подчитать страницу из сжатого образа EXE файла не выйдет.Логично что фрагментация EXE по диску при этом ни к чему хорошему не приведет.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	21. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 29-Окт-08, 16:37
	Вы не только не грамотны и не воспитаны, но ещё и читать не умеете. хорошо. вот Вам и ещё ссылка: http://www.helloworld.ru/texts/comp/lang/visualc/vc/THEORY/H... Однако файл подкачки ґ не единственный файл, используемый диспетчером виртуальной памяти. Нет особого смысла в том, чтобы записывать в этот файл страницы кода. Вместо этого Windows проецирует ЕХЕ- и DLL-модули непосредственно на их дисковые файлы. Поскольку страницы кода помечены как "только для чтения", то необходимости в их записи обратно на диск не возникает. Если два процесса используют один и тот же ЕХЕ-файл, то данный файл отображается на адресные пространства обоих процессов. Файлы, проецируемые в память, о которых мы поговорим позже, также отображаются напрямую. Они доступны "для чтения и записи" и разделяются несколькими процессами.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	23. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 29-Окт-08, 16:51
	>вот Вам и ещё ссылка: >http://www.helloworld.ru/texts/comp/lang/visualc/vc/THEORY/H... >Однако файл подкачки ґ не единственный файл, используемый диспетчером виртуальной памяти. Нет особого смысла в том, чтобы записывать в этот файл страницы кода. Вместо этого Windows проецирует ЕХЕ- и DLL-модули непосредственно на их дисковые файлы. Не совсем верно, т.к. Windows проецирует лишь те и только те секции, которые помечены ка read-only и немодифицируемые. Автоматом целый файл никуда не проецируется, т.к. могут быть bss-секции, к примеру
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	27. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 29-Окт-08, 17:35
	>Не совсем верно, т.к. Windows проецирует лишь те и только те секции, >которые помечены ка read-only и немодифицируемые. Автоматом целый файл никуда не >проецируется, т.к. могут быть bss-секции, к примеру а вот это верно! Но! разговор то шёл в рамках топика. Да и разница какая?... Особенно если в сильно нагруженной, забитой файлами (сразу вспоминаются терминальные сервера) и ОЧЕНЬ сильно фрагментированной среде?... Можно говорить, что свопом является весь диск?... Да и странички качаются случайным образом?.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 29-Окт-08, 14:23
	хотя.... будем считать, что Вы не всегда хам.... http://citforum.yspu.yar.ru/operating_systems/solaris/unix.s... Область памяти, занятая программой разделена на три части: TEXT (выполняемые коды программы), DATA (статические данные программы), STACK (динамические данные). Когда операционка освобождает место в памяти за счет TEXT'а, то она не занимается сбросом его на диск. Она сразу помечает его как свободный. Действительно, когда потребуется загрузить TEXT обратно в память, его можно будет взять из самого выполняемого файла с программой. Такая экономия имеет один побочный эффект. Файл программы, которая в данный момент выполняется, невозможно уничтожить. Операционная система сообщит в этом случае: "text file busy", и откажется выполнять удаление. похоже ведет себя и windows. вернее она только так и умеет. и при такой работе фрагментация на диске ОЧЕНЬ сильно влияет на производительность. в линухе (при его штатной настройке - 99,9%) на эту фрагментацию можно не обращать внимания вообще, т.к. проще и лучше настроить журнал и кэшь, которые этот аффект уберут.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	22. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 29-Окт-08, 16:40
	>хотя.... будем считать, что Вы не всегда хам.... Будем :) >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). С файлом подкачки ситуация не сильно меняется: дисковый кеш остается в физической ОЗУ (сколько там ее свободно). Все. Желаю успехов в изучении матчасти!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	26. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 29-Окт-08, 17:24
	много написано... и глупо... читайте комментарий выше. >Состояние у каждой страницы всего два: занята и свободна. научитесь хоть 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 , а то по-моему у Вас все смешалось в голове... как у студента перед сессией... и тем более после.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	28. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 29-Окт-08, 18:24
	>Valid, Modified, Standby, Free, Zeroed, Bad Вad не рассматриваем в нашем случае; valid, modified это значит занята, free и standby значит свободна ___если смотреть "глазами" ОС, когда какой-то процесс требует выделить ему память___. Zeroed это общем случае тоже не рассматривается. >а вот это вообще не правда >а то по-моему у Вас все смешалось в голове... как у студента перед сессией... и тем более после. Да это вы можете сколько угодно фантазировать :D Вот непонятно только, что в "схеме виртуальной памяти" винды такого, что из-за фрагментации FS в винде загрузка приложений тормозит, а в линуксе - нет??? Я услышал от вас, что есть "схожесть", но не услышал и не увидел ссылок на кардинальные _отличия VMM_ - собственно, это единственное, что мне нужно. Также впечатлает объем вашего комментария на мой достаточно большой пост - что явно говорит об уровне вашей подготовки :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	31. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 29-Окт-08, 19:17
	>Да это вы можете сколько угодно фантазировать :D Вот непонятно только, что в "схеме виртуальной памяти" винды такого, что из-за фрагментации FS в винде загрузка приложений тормозит, а в линуксе - нет??? Я услышал от вас, что есть "схожесть", но не услышал самый первый мой комментарий. в windows нельзя удалить dll, exe,... которые сейчас запущены на выполнение, а в linux я запросто произвожу update ПО, которое сейчас работает. Не понятно почему? >Также впечатлает объем вашего комментария на мой достаточно большой пост - что явно говорит об уровне вашей подготовки :) :-DDDDDD А с чего Вы взяли, что я должен Вам что-то развёрнуто доказывать? Да и на Ваше мнение о моей компетенции меня мало волнует... Тем более, что Ваш уровень я уже видел.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	29. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 29-Окт-08, 18:37
	>а вот это вообще не правда, если не сказать больше Границы дискового буфера в винде можно задать с помощю функции NtQuerySystemInformation c параметром SYSTEMCACHEINFORMATION. В который раз повторю: учите матчасть.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	32. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 29-Окт-08, 19:34
	>Границы дискового буфера в винде можно задать с помощю функции NtQuerySystemInformation c >параметром SYSTEMCACHEINFORMATION. В который раз повторю: учите матчасть. в который раз уже повторяю, что в линухе через /proc и /sys можно сделать и не такое. но это к разговору не имеет НИКАКОГО отношения.... Когда Вы объясните, почему запущенное на выполнение ПО под линух можно проапдейтить/удалить/..., а под винды - нет и как это связано с виртуальной памятью и фрагментацией на диске, тогда и появится у Вас право давать кому-нибудь советы. А пока что... учите матчасть. :-DDDDDDDDDDDDDDDDDDDDDDD (а то в комменте 10 Вы вообще утверждали, что в виндах бинарник свопиться,.. хорошо хоть одумались под конец)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	34. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от ананимка on 29-Окт-08, 23:30
	>Границы дискового буфера в винде можно задать с помощю функции NtQuerySystemInformation c >параметром SYSTEMCACHEINFORMATION. В который раз повторю: учите матчасть. А выполняется она от рута? пьху!!! админа? Или каждый желающий? А то было бы забавно;-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	38. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от User294 (ok) on 30-Окт-08, 04:19
	>А выполняется она от рута? пьху!!! админа? Мде, попробовал документацию на эту функцию почитать... как вам такое описание? http://msdn.microsoft.com/en-us/library/ms724509(VS.85).aspx Такое ощущение что писал его почтальон Печкин - дескать, посылка у меня есть но вам я ее не отдам.Описание явно писалось по этому же принципу :)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	41. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от vitek (??) on 30-Окт-08, 07:04
	эта функция, NtQuerySystemInformation, только возвращает некоторую информацию о системе, а не изменяет её. и из названия это следует. но к разговору это не относится. :-)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Алексей (??) on 29-Окт-08, 14:26
	Windows никогда не свопирует выполняемый код, т.к. априори предполагает, что а) он неизменяем б) его всегда без проблем можно заново считать из запускаемого файла (кстати именно поэтому при использовании пакеров exe-файлов Windows приходится свопить весь распакованый exe-файл в своп). Свопируются только данные! Поэтому все ваши наезды вообще говоря не понятны.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	24. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 29-Окт-08, 16:54
	>Windows никогда не свопирует выполняемый код, т.к. априори предполагает, что >а) он неизменяем >б) его всегда без проблем можно заново считать из запускаемого файла >(кстати именно поэтому при использовании пакеров exe-файлов Windows приходится свопить весь распакованый >exe-файл в своп). > >Свопируются только данные! Поэтому все ваши наезды вообще говоря не понятны. И вам повторю: свопирутся секции, согласно флагам, и никаких "априори"
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	33. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от ананимка on 29-Окт-08, 19:57
	>И вам повторю: свопирутся секции, согласно флагам, и никаких "априори" Без разницы весь файл или его части. Важен результат. А он известен - переустановка винды. И диск желательно переразбить.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	37. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от User294 (ok) on 30-Окт-08, 02:58
	>И вам повторю: свопирутся секции, согласно флагам, и никаких "априори" Если дефолты рассмотреть и как оно обычно происходит без всякой экзотики - как раз обычно получается размазанный по всему диску "своп" потому что система зачастую подчитывает страницы из EXE файлов а не из свопа.И априори, по дефолту, в поставке винды ехешники сделаны именно так, насколько я знаю. У вас есть что-то возразить по делу и вам есть чем оспорить тот факт что фрагментация в этом случае все усугубляет?Или вы так, софистикой занимаетесь чтобы отмыться от какашек которые в вас полетели?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от User294 (ok) on 28-Окт-08, 23:17
	>300 гигов, ага Не хочу ничего сказать но это зачастую весьма быстрый способ дефрагментации сильно засранного и изрядно забитого тома :).Дефрагер не может позволить себе такой роскощи в общем случае и потому обычно вынужден изощренно изгаляться передвигая куски файлов туда-сюда при том на одном физическом девайсе, что вообще-то довольно мееееедленно(при описанном методе в лучшем случае 2 физических девайса будут работать впараллель - с 1го HDD читаем, на 2й временно складываем).На засраном томе много перемещений кусков файлов делается дефрагером вовсе не для того чтобы сделать что-то полезное а просто как служебное действие для расчистки места чтобы можно было выстроить какой-то файл как непрерывный кусок.Если дефрагить дефрагером сильно фрагментированый и забитый том на 300 гиг - это выглядит медленно и печально.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от fix (??) on 29-Окт-08, 04:13
	С одной стороны это так. Но и для Win-разделов можно использовать такой приём, хотя для них давно имеются стабильный штатные дефрагментаторы. А если под рукой может не оказаться ещё одного винта, равного по объёму? А если винт физически недоступен? Ну несерьёзно это. Разумеется, мне могут ответить "возьми и напиши". Готов признаться, что не обладаю ни достаточным опытом и знаниями в этом предмете, ни временем, чтобы взяться за такую серьёзную задачу. Кроме того, необходимо плотное тестирование, что тоже нелегко организовать. Схема организации виртуальной памяти в win имеет свои преимущества. Скажем, сравните время холодного старта OO и MSO.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	19. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от demon (??) on 29-Окт-08, 15:44
	а-ха-ха !!! товарищ Аноним... вы ещё сошлитесь на сообщения при установке виндов... где пишет, что она самая быстрая и удобная... А уж API виндовое для дефрагментации NTFS было оплёвано и обосранно всеми, кто его имел неосторожность посмотреть... то-то Нортоновский SpeedDisk в обход работал, и умел то, что остальным дефрагментаторам только снилось. не забывайте, что при заполнении - NTFS начинает резать MFT, а при "выходе из кризиса" потом снова увеличивать... только уже в свободное фрагментированное место... и ничего с этим не поделать... ... и никто давно не замарачивается - просто переустанавливают заново винду и радуются, что она снова быстро работает... а так-то да... MSDN... Балмер...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	20. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от User294 (ok) on 29-Окт-08, 15:54
	>хотя для них давно имеются стабильный штатные дефрагментаторы. Я попробовал запустить штатный дефраг на засраном NTFS разделе в 40 гиг (всего 40 гиг!!!).Он за 12 часов (ночь) не справился!Это не дефрагер а декоративная бня!Особенно учтя то что файлы эта дребедень не дефрагментирует и пытается только создать непрерывную область свободного места.А как при этом будут раскиданы файлы - этот чудо дефрагер (как минимум в XP и 2003) совершенно не колышет.Если честно то толка с такого дефрагера почти нуль.Ну похрустел он 12 часов головами.И что изменилось?У нортона неплохой дефраг, сравнительно быстрый на не очень засраных дисках.Но глюкастый..... бывало даже разрушение данных оным.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	25. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от Аноним (??) on 29-Окт-08, 16:58
	>Я попробовал запустить штатный дефраг на засраном NTFS разделе в 40 гиг >(всего 40 гиг!!!).Он за 12 часов (ночь) не справился!Это не дефрагер >а декоративная бня!Особенно учтя то что файлы эта дребедень не дефрагментирует >и пытается только создать непрерывную область свободного места.А как при этом >будут раскиданы файлы - этот чудо дефрагер (как минимум в XP >и 2003) совершенно не колышет.Если честно то толка с такого дефрагера >почти нуль.Ну похрустел он 12 часов головами.И что изменилось?У нортона неплохой >дефраг, сравнительно быстрый на не очень засраных дисках.Но глюкастый..... бывало даже >разрушение данных оным. рекомендую PerfectDisk
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	36. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от User294 (ok) on 30-Окт-08, 02:42
	>рекомендую PerfectDisk А он JFS, XFS и EXT3 жрет?Если нет - для меня он на данный момент уже достаточно бесполезный артефакт, потому что от виндов я везде где мог избавился: так мне определенно меньше головняка с майнтенансом систем =).В свое время в винде нортон радовал.Пока не упал при дефраге, оставив некоторое количество файлов основательно испорчеными... гибкость его настроек и скорость работы это конечно хорошо, но вот такой фортель как-то отбил охоту вообще лишний раз юзать дефрагеры :-\.На наиболее засраном томе (250Gb EXT3 забитый на 95%) у мну фрагментация порядка 3%.На виндовых дисках я и 40% видал, а 3% вообще имхо не повод дергаться. P.S. насчет дефрагов... для истинных мастеров цифровых дел способных размещать файлы так как им захочется есть забавная идея :).Было бы гуд если бы кто-то дотумкал уже оптимизировать LiveCD так чтобы доступ к файлам был более-менее последовательным в ходе загрузки с оного.Для этого вероятно может оказаться достаточно выстроить файлы на исохе в порядке в котором они читаются при загрузке :).Навеяно воспоминаниями о том как CD-ROM натужно гоняет головы туда-сюда при загрузке с ливцд а у сидюков это намного медленнее чем у HDD и там "дефрагментация" (хоть это и не дефрагментация) поактуальнее на пару порядков ;)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	30. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от fix (??) on 29-Окт-08, 19:10
	>файлы эта дребедень не дефрагментирует и пытается >только создать непрерывную область свободного места ерунда. файлы он дефрагментирует >Ну похрустел он 12 часов головами.И что изменилось? ускорилась работа OC. заметно даже визуально >У нортона неплохой дефраг, сравнительно быстрый на не очень засраных дисках. >Но глюкастый..... бывало даже разрушение данных оным. здесь все понимают смысл слов "стабильный" и "быстрый"? P.S. высер demon-а оставлю без внимания
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	35. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от demon (??) on 30-Окт-08, 00:17
	fix, оставил бы, если б не PSыкал ----------- проблема дефрагментации NTFS в том, что лучше её не производить вообще, а значит не забивать NTFS раздел более чем на 85% Если всё-же дефрагментация случилась.. придётся её производить с завидным постоянством, т.к. фрагментирование NTFS после дефрагментации  - катастрофически возрастает (уж об этом писано-переписано) Отсюда и получается, что и для NTFS - копирование пресловутых 300 гигов - наилучший способ...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	40. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от User294 (ok) on 30-Окт-08, 05:06
	>ерунда. файлы он дефрагментирует Как-то ради интереса гонял дефрагер XP на небольшом разделе (на большом и засраном он работает абсолютно невменяемо по времени) а потом посмотрел что он там нафигачил нортоном(у него карта диска довольно удобная).Налицо была вермишель из файлов - полной дефрагментации дефрагером не было сделано.Свободное место - да, объединено, а файлы остались фрагментированы, может поменьше но уж никак не лежали одним непрерывным блоком.У нортона кстати есть такой режим - для быстрой (и достаточно халтурной) дефрагментации.Еще нортон умеет грамотно оставлять после хвоста файла место на grow файла - иногда разумно даже. >>Ну похрустел он 12 часов головами.И что изменилось? >ускорилась работа OC. заметно даже визуально Ага, черта с два... тот раздел как был тормозной засраной помойкой так и остался таковой.За 12 часов так особо лучше и не стало.Я честно говоря не знаю нахрен такой дефрагер нужен - пахать ему неделю на 40 гиговом разделе никто не даст а если для этого 12 часов мало - тут я пас.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	39. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от User294 (ok) on 30-Окт-08, 04:56
	>Ну несерьёзно это. >Разумеется, мне могут ответить "возьми и напиши". Да вообще где-то болтается скрипт который хоть и немного читерски но дефрагит почти любую ФС - пофайлово.Читерство, ибо не дефраг в привычном понимании но степень фрагментации судя по отзывам снижает (disclaimer: меня фрагментация не допекает и посему лично я это не тестировал). >Схема организации виртуальной памяти в win имеет свои преимущества. Скажем, сравните время >холодного старта OO и MSO. Интересно что вы хотели этим сказать?Кого и где надо сравнивать?А то OO есть под виндовс например.Он и там не больно резво стартует.Или имелось в виду что MSO стартует быстрее потому что использует какие-то недокументированные функции по части управления виртуальной памятью?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	42. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от . on 30-Окт-08, 11:16
	>OO есть под виндовс например.Он и там не больно резво стартует Резвее, чем в nix. Дело даже не в способах линковки. Просто есть ощутимая разница между "прочитать 200 мегабайт" и "прочитать 200 мегабайт, записать 180 мегабайт" (образно говоря). Да, с мощными камнями и большим объёмом оперативы разница стирается. Файлы в ntfs дефрагментируются, хоть и не все. Открой диск редактором и посмотри.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	43. "Подробное руководство по тюнингу файловой системы Ext3"
	Сообщение от User294 (ok) on 02-Ноя-08, 09:21
	>ощутимая разница между "прочитать 200 мегабайт" и "прочитать 200 мегабайт, записать >180 мегабайт" То есть, допускается что есть 20 мегов оперативы и в них пытается запихнуться офис?Ну да, круто.Только тормозить будет полюбому - уж не думаете ли вы что 180 мегов выдавятся в своп только для того чтобы никогда больше не прочитаться?А значит такую работу будет 1 хрен сопровождать хруст харда.И подчитаются ли страницы из ехешника или из свопа - в конечном итоге не так важно.Будет медленно и печально.При чтении из кучи файла по всему диску к тому же медленнее и печальнее.Винды вообще своплением раздражают.Если жирную программу 2 часа не трогать и поработать с другой программой - при попытке вернуться в ту программу будут жесточайшие тормоза пока оно там из свопов все подчитает.При том - оно так даже когда оперативка в общем то и не заканчивалась.В результате в винде весьма противно работать с несколькими увесистыми программами например - натужный хруст харда и тормознутый отклик программ гарантирован.Линуксы этим не страдают - они лезут в своп только когда натурально приперло.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]