LINUX.ORG.RU

Что в дистрибутиве Linux больше всего использует дисковую подсистему.

1. система в момент старта

2. приложения в момент старта

3. кэш/своп, если памяти мало

4. разнообразные индексации/обновления. Но их можно и отключить, если задолбали и не нужны

5. кеши самих программ. Это надо выносить в последнюю очередь, ибо программа без них будет стартовать с чистого листа, и потому стартовать долго и нудно восстанавливая свои потерянные кеши. И на эти кеши дурно влияет так любимый кулцхакерами noatime. Он приводит к тому, что программа не знает, что ей нужно, а что не нужно, и прибивает первое попавшееся. И сразу качает/считает обратно. Мучительно долго стрекача диском...

drBatty ★★
()
Ответ на: комментарий от drBatty

Думаю разделить систему на два диска без рейда. И разместить критичные к быстродействию компоненты системы в начале дисков.

slyakusha
() автор топика
Ответ на: комментарий от beresk_let

Логи забыл.

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

drBatty ★★
()
Ответ на: комментарий от slyakusha

лучше SSD купи небольшой, и _всю_ систему туда. И большинство юзерских данных тоже (всякие кеши браузера, ~/.kde, и т.д.)

И разместить критичные к быстродействию компоненты системы в начале дисков.

там профит больше не из-за «начала», а из-за того, что основные данные сгруппированы в маленькой области, и головке надо меньше прыгать в поисках файлов. Можно и в конец зафигачить, разница не заметна(мне не заметна). А вот если по всему диску раскидть, то slooow...

drBatty ★★
()
Ответ на: комментарий от drBatty

само ядро вообще не использует. Его как лоадер загрузит, так и можно смело стирать с диска.

Ты не понял сути. Всё общение с диском проходит через вызовы ядра.

i-rinat ★★★★★
()
Ответ на: комментарий от drBatty

А при чём тут моя квалификация? Логи и журналирование нагружают диск, это факт. Насколько сильно и как это можно настроить — совершенно другой вопрос. Если уж называть индексацию и кэши программ (которые тоже настраиваются, коли на то пошло), то почему остальное не упомянуть?

beresk_let ★★★★★
()
Ответ на: комментарий от i-rinat

Ты не понял сути. Всё общение с диском проходит через вызовы ядра.

а больше всего энергии тратит твой рот :-)

drBatty ★★
()
Ответ на: комментарий от drBatty

Я склоняюсь к мысли, что в любом случае лучше использовать два и более дисков. Например, один под систему, другой для архива. Даже без ssd.

slyakusha
() автор топика
Ответ на: комментарий от beresk_let

Если уж называть индексацию и кэши программ (которые тоже настраиваются, коли на то пошло), то почему остальное не упомянуть?

потому-что это уже «второй порядок малости», этим можно и пренебречь без особого вреда для точности. По сравнению с теми-же кешами программ, которые для того-же браузера могут дать немалое падение быстродействия. А mandriva у меня так вообще висла каждые три часа при обновлении — потому-как за три часа кеш вытесняется другими файлами, а при обновлении Over9000 файлов читаются обратно в память. 12309 во все поля.

Логи нагружают только ту систему, в которой что-то не так. И исправлять/настраивать надо не логи.

drBatty ★★
()
Ответ на: комментарий от slyakusha

Я склоняюсь к мысли, что в любом случае лучше использовать два и более дисков. Например, один под систему, другой для архива. Даже без ssd.

ну два HDD всяко не медленнее одного.

drBatty ★★
()
Ответ на: комментарий от drBatty

Кеш разве не в оперативке находится? Который отвечает за пуск программ, например. При повторном обращении к данным читает из оперативки.

slyakusha
() автор топика
Ответ на: комментарий от drBatty

там профит больше не из-за «начала», а из-за того, что основные данные сгруппированы в маленькой области

Из-за начала тоже. Я так считаю.

slyakusha
() автор топика
Ответ на: комментарий от slyakusha

При повторном обращении к данным читает из оперативки.

ну это при повторном. К тому-же, читать из кеша ты можешь из памяти, а вот писать — извините, и туда, и суда. Проблема HDD как раз в рандомной записи, изменить Over9000 кусков в Over9000 раз дольше чем один, суммарного размера. Потому, даже небольшой объём записи в кеш сильно тормозит всю систему.

И ещё atime надо менять или что-то подобное(firefox ЕМНИП меняет sqlite базу с той же целью), т.е. даже если только читать, писать всё равно придётся. А если статистику не собирать, то непонятно что вытеснять из такого кеша.

Из-за начала тоже. Я так считаю.

мы тут в том году спорили и мерили. Да, в начале быстрее. Но всё равно, головка движется между головками НАМНОГО медленнее, чем диск крутится. Крутится он довольно быстро, и данных довольно много. Даже в конце диска.

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

drBatty ★★
()
Ответ на: комментарий от drBatty

мы тут в том году спорили и мерили. Да, в начале быстрее.

А чего тут мерить? Угловая скорость ближе к центру магнитного диска больше.

slyakusha
() автор топика
Ответ на: комментарий от slyakusha

А чего тут мерить? Угловая скорость ближе к центру магнитного диска больше.

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

drBatty ★★
()
Ответ на: комментарий от slyakusha

Угловая скорость ближе к центру магнитного диска больше.

Да, чего только в интернетах не прочитаешь.

greenman ★★★★★
()
Ответ на: комментарий от drBatty

само ядро вообще не использует. Его как лоадер загрузит, так и можно смело стирать с диска

В школу свали с таким «умничаньем».

anonymous
()
Ответ на: комментарий от anonymous

само ядро вообще не использует. Его как лоадер загрузит, так и можно смело стирать с диска

В школу свали с таким «умничаньем».

можешь проверить если сомневаешься.

drBatty ★★
()
Ответ на: комментарий от greenman

Да, чего только в интернетах не прочитаешь.

ну типа перепутал линейную с угловой и ближе с дальше. А так всё верно. Ну и ещё не учёл, что плотность данных внутри больше, потому скорость чтения/записи более-менее постоянная. Да и вообще, кто хоть раз разбирал HDD знает, что разница в размере дорожек не слишком и большая.

drBatty ★★
()
Ответ на: комментарий от drBatty

Можешь попытаться, для начала, провести логическую связь между вот этим

само ядро вообще не использует.

и вот этим

Его как лоадер загрузит, так и можно смело стирать с диска

из твоего поста, иначе проверять нечего.

anonymous
()
Ответ на: комментарий от drBatty

ну типа перепутал линейную с угловой и ближе с дальше.

Либо перепутал HDD с CD (DVD).

greenman ★★★★★
()
Ответ на: комментарий от anonymous

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

Потому говорить «ядро использует HDD» может только идиот или неуч, единственное «использование» — загрузка с /boot/, которая, кстати тоже не нуждается в HDD, у меня вот с флешки грузится, а дисков/SSD тупо НЕТ.

drBatty ★★
()
Ответ на: комментарий от drBatty

4. Но их можно не ставить если, задолбали и не нужны

fxd
как истинный слакварщик ты должен был написать именно так :3

smilessss ★★★★★
()
Ответ на: комментарий от drBatty

и хватит демагогии: ядро «использует HDD» точно также, как использует его провода к этому HDD. Не больше и не меньше.

drBatty ★★
()
Ответ на: комментарий от smilessss

как истинный слакварщик ты должен был написать именно так :3

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

drBatty ★★
()
Ответ на: комментарий от drBatty

ибо пытаешься доказать, что в слаке нихрена не работает.

Никто этого не говорил.
А написал я так ибо в моём арче нет никаких

средств индексации

Всё оно либо отключено, либо не установлено.

smilessss ★★★★★
()
Ответ на: комментарий от smilessss

Всё оно либо отключено, либо не установлено.

тогда и спорить нам не о чём.

drBatty ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.