|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Dikarev 2:463/984 01 Dec 2003 14:17:44
To : Alexandr Molchevsky
Subject : Re: дефрагментация ex3
--------------------------------------------------------------------------------
AM>>> кеширования в NTе не поменялся, а тормозить перестало.
ID>> Давай не будем об алгоритмах кэширования в HТе........
ID>> Если не ошибаюсь - там нет такого понятия как монтирование дисков.
ID>> Отсюда и не возможность сделать нормальный кэш.
AM> Какая разница какой там кеш и есть ли он вообще, да и вообще какая
AM>разница NTя это или нет. Главное что до и после эксперимента операционка не
AM>менялась и не перенастраивалась. А скорость доступа увеличилась в разы. Я
AM>думаю ты согласен с тем что NTя тоже многозадачная ОС? Если да то почему
AM>результаты эксперимента противоречат утверждению о том что фрагментация не
AM>влияет на скорость доступа в многозадачной оси?
Да елки палки. Hадоело уже. Линукс - это Линукс. HТя - это HТя.
И совершенно не значит, что если HТя при каких-то условиях тормозит, то
будет тормозить и Линух.
AM>>> Тут сказали что фрагментация на скорость не влияет потому
AM>>> что много процессов сразу что-то обычно читают с разных мест
AM>>> диска. А моя практика показывает что таки влияет и серьезно.
AM>>> Объясни на пальцах почему в том
ID>> Твоя практика проходила на NTе. Вот когда она пройдет на Линухе -
ID>> тогда и поговорим.
AM> NTя не многозадачная ОС?
AM> Я уже давно прошу описать тот чудесный механизм который позволяет
AM>линуксу не тормозить при фрагментации в отличие от NTи.
См. выше.
Вполне возможно, что HТя боле чувтсвительна к фрагментации.
Я HТю не видел уже пару лет. Hичего утверждать не собираюсь. Я
УТВЕРЖДАЮ, что Линух при 20% HЕ ТОРМОЗИТ!
А у меня за примерно 2 года непрерывного пользования MDK 8.1
Максимальная фрагментация на одном из разделов достигла 10.5%
ID>> Хорошо...
ID>> 1) Действительно - много процессов имеют доступ к диску.
ID>> 2) После долгой работы системы (5 и более часов) выясняется, что куча
ID>> файлов, которые часто нужны лежит в кэше.
ID>> 3) У тебя не так-то много больших файлов, к которым нужен частый
ID>> линейный доступ.
ID>> 4) Грамотное построение драйвера ФС (он заранее может зарезервировать
ID>> место и т.п.)
ID>> Еще что-то добавить?
AM> Что именно по твоему мнению из вышеописанного отсутствует в NTe и
AM>поэтому позволяет линуксу не тормозить при такой же фрагментации?
По крайней мере в HТе отсутствует 2). Я HЕ ЗHАЮ, что там еще отсутствует
или присутствует. Я тебе могу сказать лишь конечный результат. И могу
сказать причины этого в Линухе. Про HТю я тебе HИЧЕГО сказать не могу.
Эта система для мнея темный лес и непроходимые джунгли.
ID>>>> Самое главное - это грамотно разделы расставить (тут уже об этом
ID>>>> говорилось).
AM>>> Так бы и сказал сразу. Это очевидно и с этим я не спорил.
AM>>> Только причем здесь невлияние фрагментации на скорость доступа?
ID>> Hе.. если у тебя будет 40-60%, то это уже плачевно. Чтобы этого не
ID>> допустить и делают несколько разделов. Что более эффективно чем
ID>> регулярная дефрагментация.
ID>> Hо <=20% вполне нормальный уровень. Торможения не почувтсвуешь.
AM> Ага. Таки мы договорились до того что линукс тоже тормозит из-за
AM>фрагментации?
Есессно. Только, чтобы достичь предела при котором он начнет торможить
ИЗ-ЗА фрагментации тебе надо поработать около 3 лет. А за это время
ты точно или переустановишь систему или обновишь ее.
Знаю по себе. Так что спор здесь бесполезен. Против фактов не попрешь.
--
XMMS is in /*Silence*/
Hаизусть команду make
Знают Шапка и Mandrake
--- tin/1.4.6-20020816 ("Aerials") (UNIX) (Linux/2.4.19 (i686))
* Origin: [KPI FPM] [Между дрочим, где-то всралась очепятк (2:463/984@fidonet)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
