From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Sat, 17 Mar 2007 02:13:44 -0400 From: Ivan Adzhubey In-reply-to: <20070317014435.GD27576@basalt.office.altlinux.org> To: ALT Linux Sisyphus discussion list Message-id: <200703170213.44702.iadzhubey@rics.bwh.harvard.edu> MIME-version: 1.0 Content-type: text/plain; charset=koi8-r Content-transfer-encoding: 8BIT Content-disposition: inline References: <200703161526.53469.iadzhubey@rics.bwh.harvard.edu> <20070316225008.GN18375@osdn.org.ua> <20070317014435.GD27576@basalt.office.altlinux.org> User-Agent: KMail/1.9.6 Subject: Re: [sisyphus] =?koi8-r?b?L3RtcCDOwSB0bXBmcz8=?= X-BeenThere: sisyphus@lists.altlinux.org X-Mailman-Version: 2.1.9rc1 Precedence: list Reply-To: ALT Linux Sisyphus discussion list List-Id: ALT Linux Sisyphus discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2007 06:14:01 -0000 Archived-At: List-Archive: List-Post: On Friday 16 March 2007 09:44:35 pm Dmitry V. Levin wrote: > On Sat, Mar 17, 2007 at 12:50:08AM +0200, Michael Shigorin wrote: > > On Fri, Mar 16, 2007 at 03:26:53PM -0400, Ivan Adzhubey wrote: > > > Последним обновлением (setup-2.2.10-alt1) создало > > > /etc/fstab.rpmnew с такой строчкой: > > > tmpfs /tmp tmpfs nosuid 0 0 > > > Это новая политика партии? > > > > Некоторые так после нагрузочного тестирования делали > > ещё года четыре тому. > > > > > Я помню, обсуждалась возможность такой конфигурации, но это > > > было давно и к консенсусу тогда кажется так и не пришли. > > > В changelog пакета написано незатейливо: "/etc/fstab: Added > > > /tmp entry." А аргументы? > > > > Чистить не надо, например. Опять же раздел, выделенный под /tmp, > > можно пустить под своп с не меньшим эффектом. > > > > Проблемы бывают при большой нагрузке на VM -- потеря файлов. > > Для /tmp это скорее приемлемо. > > > > Мне вот только интересно, что с /tmp/.private при этом будет. > > (не подумайте, что в восторге от _этого_, но в bugzilla меня > > проигнорировали) > > Я не очень люблю вести обсуждения в bugzilla - этот инструмент для > напоминания об ошибках не предназначен для обсуждения. > Давайте лучше обсуждать здесь. > > Что касается /tmp на swap'е по умолчанию в новых системах, то я не вижу > ни одного реального минуса в этом подходе. Я тоже не вижу минусов, просто потому, что ничего не знаю про tmpfs, ее текущее состояние в 2.6.x, переспективы, надежность и пр. Если мне кто-нибудь расскажет или покажет где смотреть - буду признателен. Пока гуглю понемногу, но это не лучший способ получения достоверной информации. Вижу, что она использует виртуальную память и своп для временного хранения неиспользуемых файлов. Как минимум, это значит, что размер свопа должен быть теперь увязан не только с размером физической памяти и требованиями запускаемых приложений, но и с требованиями к размеру /tmp. Для "среднестатистического" десктопа это может быть и не очень важно, но серверы-то бывают разные. У меня например есть один, у которого /tmp под нагрузкой занимет 2/3 диска, такие там приложения крутятся. Вряд ли я смогу его просто переключить на tmpfs без переразбивки диска. Да и непонятно, что произойдет с производительностью задач интенсивно использующих файлы в /tmp. Про проблемы с /tmp/.private я вообще ничего не понял, обсуждение в этой рассылке было коротким и загадочным. --Иван