The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Индекс форумов
Составление сообщения

Исходное сообщение
"Релиз ядра Linux 3.14. Обзор новшеств"
Отправлено www2, 31-Мрт-14 19:06 
> 1). Берём легко сжимаемые данные.
> 2). Помещаем их в ZRAM, забив всё доступное место. Например 8 Гб
> при физически доступных 2 Гб.
> 3). Внезапно удаляем 8 Гб легко сжимаемых данных и забиваем тяжело сжимаемыми
> данными, например H264-видео.
> 4). ????
> 5). Kernel Panic.

И при чём тут сжимаемость данных? Все 8 гигабайт этого видео не потребуются одновременно - это раз. Во-вторых - они есть на диске, зачем их все грузить? Лучше читать по мере необходимости с небольшим упреждением. Ну и наконец, можно же использовать двухуровневую систему подкачки, или даже трёхуровневую - zRAM, раздел подкачки на SSD-диске, раздел подкачки на диске со шпинделем. Реже используемые данные вытесняются на более медленную систему.

>Ну серьёзно, зачем умещать 700 Мб в 500 Мб, если внезапно может заполниться память?

Медленным жёстким диском не пользоваться без необходимости - вот зачем. Когда действительно будет нехватка оперативки - что-ж, придётся воспользоваться разделом подкачки на жёстком диске.

>Зачем вообще хранить SWAP в памяти?!

Зачем дисковый кэш в памяти хранится? Чудик, ты вообще знаешь, что в Linux практически не бывает свободной, в полном смысле этого слова, оперативной памяти? Если есть свободная память, Linux будет использовать её в качестве дискового кэша, чтобы не читать с медленного жёсткого диска то, что уже раньше читалось. Всё равно она без дела простаивает.

>И это уже традиция в Linux. То фирменную технологию Google примут в ядро, которая позволяет на гигабайтной флешке создать сто стогигабайтных файлов, потому что "У нас на GMail лишь 1% использует все свои 100 Гб почты, так нафига месту простаивать?".

Вообще-то, в Unix'ах отродясь на диске место не занимается, если в него ничего не писалось. Можно открыть файл на запись, промотать 100 гигабайт и записать один байт. Файл будет иметь размер 100 гигабайт с хвостиком, но реально будет занимать на диске только объём этого хвостика. Утилиты dumpfs и restorefs - единственные, кто это свойство умеет учитывать и не тратить зря место на "магнитной ленте".

Гугель лишь изобрёл велосипед, под свои собственные нужды.

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

Не мифической, а очень даже реальной. СУБД может сотни раз в секунду перезаписывать одни и те же данные. Сделать сотни записей на диск или одну - есть разница?

Воинствующее невежество ты наше, потреблять от ИТ. Если ты видишь глупость, то тут обычно есть два варианта - либо это действительно глупость, либо это не глупость, а просто ты чего-то не понял. Но твой межушный ганглий до второго варианта додуматься не может и поэтому сразу бросается вопить.

 

Ваше сообщение
Имя*:
EMail:
Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email).
Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:
 
При общении не допускается: неуважительное отношение к собеседнику, хамство, унизительное обращение, ненормативная лексика, переход на личности, агрессивное поведение, обесценивание собеседника, провоцирование флейма голословными и заведомо ложными заявлениями. Не отвечайте на сообщения, явно нарушающие правила - удаляются не только сами нарушения, но и все ответы на них. Лог модерирования.



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру