Bluetooth писал(а): ↑04.02.2010 01:31
Ос сама так делает, но весь дисковый кэш прокси у нее дурости не хватит в кеше хранить smile.gif
И к тому же это не отменяет i/o с диском.
А насчет сохранения - не страшно, если потеряется часть кеша при сбое питания, поэтому необязательно будет часто бэкапить тмпфс(но нужно это делать грамотно, с копированием только изменившихся объектов, и с учетом специфики работы кэша, а не все подряд копировать smile.gif ). А в остальных случаях кэш можно будет безопасно сохранить при стопе сервиса, и восстановить заново при старте. Только при большом объеме кэша это все будет занимать довольно таки долгое время... smile.gif
действительно - полезная оптимизация. вот куплю памяти - тоже так сделаю
Bluetooth писал(а): ↑04.02.2010 01:31
Что за 4 мб? я не в теме
у оперы в настройках можно явно указать объём кеша в RAM. Например 4Мб. Возможно опера как раз и использует tmpfs для этого.
Davinel писал(а): ↑04.02.2010 01:33
ОС так не делает. ОС читает с диска, что то делает, записывает на диск, опять читает с диска и т.д.
А тут все операции в памяти и только после завершения - сброс на диск.
ОС читает с диска
в память, что-то делает... и т.д.
Но есть такая вещь, как отложенная запись и отложенное удаление - ОС вправе не писать на диск некоторые данные, либо писать их после того, как она их "записала". Например: выполняю команду
rm big_file
команда исполняется, и я опять в оболочке. Однако, некоторое время HDD ещё мигает лампочкой и что-то там пишет, хотя файла уже "нет". С записью происходят ещё более удивительные вещи. ОС докладывает: "запись выполнена" - хотя она даже и не подумала что-то куда-то записать - у неё есть дела поважнее. Точно так-же работает и кеш внутри диска - ответ от HDD об успешной записи приходит ДО начала этой записи - если вырубить питание, то мотор диска превращается в генератор, и на последних оборотах экстренно сбрасывает всё на диск и паркует дорожки. С ОС сложнее - у неё нет генератора, за то есть журналируемая ФС - иногда помогает
Davinel писал(а): ↑04.02.2010 01:33
Вообще при желании можно извратиться и записать файрфокс(ну или там хром) на тмпфс целиком.
Копировать его туда каждый раз при запуске компьютера, тоже самое с конфигом + делать rsync каждые минут 5-10(оно куда энергоэффективнее чем тар, поэтому легко можно часто делать, замедлений практически не будет)
не парьтесь, возьмите любой LiveCD.
(кстати, видели-бы вы как жутко тормозит Mandriva LiveCD на 512и МБ...)
Bluetooth писал(а): ↑04.02.2010 04:46
Видимо, он имел ввиду кеш оси.
То есть ос читается с диска, кладет в кеш, что-то делает, пишет на диск, но в следующий раз опять читает не с диска, а из кеша, если оно там осталось. Это как я понимаю
ага. только она и пишет тоже в кеш. причём завершение записи == завершение записи в кеш. записанные данные могут вообще никогда не появляться на диске, например если мы их успеем переписать до того, как они сбросятся на диск..
Bluetooth писал(а): ↑04.02.2010 04:46
В случае с бд, кстати, есть еще и проблема, что мы можем получить неконсистентную бд, если во время синка будет в нее что-то писаться.
конечно получим! потому БД перед этим нужно переводить в READONLY.
Bluetooth писал(а): ↑04.02.2010 04:46
Эти же проблемы всегда стоят и перед теми, кто бэкапит базу во время ее работы.
к счастью, это не слишком страшно. например: вы пишете ответ в этот форум, и нажимаете кнопку "отправить" - вам не везёт, в этот момент работает mysqldump. На самом деле ничего страшного - эта команда работает довольно быстро, и вам просто придётся подождать секунду-другую (хотя я не знаю точный размер базы этого форума и скорость этого сервера, если сервер тормозной, а база большая - ждать придётся дольше, вплоть до Error 504)
smaharbA писал(а): ↑04.02.2010 09:35
(по сути реализация свопа (выгружаемые пулы и прочие статики) в той же ненавистной виндуз сделана гораздо грамотнее)
ага. я заметил сравнивая работу нескольких ОС при недостатке памяти. Не смешите пожалуйста.