А что, IMHO, tmpfs - правильно.
Делаем здоровый swap partition, и переносим /tmp в tmpfs.

Чегото я не понял всей мазы ентой fs, может кто расскажет?

Маза такая ( ИМХО самое полезное ).
Жмешь в mc enter на каком-нть архиве, он распаковывается в /tmp,
а потом ты копируешь его содержимое куда-нибудь.
С обычной /tmp
архив(диск) -> /tmp(диск) ( распаковка )
/tmp (диск) -> final destination (диск)

С tmpfs
архив(диск) -> /tmp(память) ( распаковка )
/tmp (пямять) -> final destination (диск)

Итого кол-во дисковых операций сокращено в двое.

Ну если только для того чтоб в mc на архивы давить, то это сильное преймущество:))
не говоря о том, что если памяти достаточно и есть свободные буфера то непосредственно до диска при обычном tmp дело вообще может не дойти, а если и доходит (sync) то не так быстро.

А что будет, если несколько пользователей решат одновременно
собрать по ядру (и, соотвественно, пораспаковывать оное средствами mc -
ну, чайники, положем, только что с FAR`а :) ) на машинке со,
скажем, 96 метрами памяти?

P.S. Sorry, не читал пока...

2ifconfig:
вот чтоб не было sync и придумали tmpfs

ну ещё мелкие фичи, типа распределения по нескольким свапам

Тут уже пролетало, что с ext2 использование
tmpfs не имеет большого смысла.

Статью то уж прочитайте сначала...

> А что будет, если несколько пользователей решат одновременно
собрать по ядру

Несколько рутов одновременно на одной машине? :)

> Несколько рутов одновременно на одной машине? :)
Кто Вам сказал, что ядро должны собирать root-ы? :-)

Для mc оно как раз не актуально.
Hint: Have you plenty of RAM/Virtual RAM? Set the tar VFS memlimit to -1.

Давно искал shared memory с внутренней структурой, похожей на файловую.
Раньше приходилось каждый раз данные между процессами гонять:
запаковать-рапаковать-запаковать-распаковать-... А теперь все благополучно в фс ляжет
и времени на упаковку данных для передачи другим процессам не нужно.
ИМХО для этого tmpfs и создавалась.

http://www.tux.org/lkml/#s9-12
-> How about tmpfs for Linux?

Nakonec-ko Linuxoidy sdelali to, chto v tom zhe Solaris sushestvovalo uzhe davnym-davno :)

А может оно не надо было. Потому и не делали. А теперь добрый студент решил курсовик написать. И написал.

> Несколько рутов одновременно на одной машине? :)

По хорошему у root-а нет полномочий на сборки, он только инсталлирует :)

Эх, если бы память в Unix-ах была одноуровневой, без жесткого разграничения ОЗУ/область данных/область swap - это было бы "оно".

Если бы ещё и приватную, для каждого процесса TMPFS - вообще "самое оно".
А так - несколько опасная штука...

Для непонимающих зачем оно.
Слава богу, что никто не знает кто я ;)
Symptom

Sie wollen den vorhandenen Hauptspeicher für SAP auf Linux effizienter

nutzen und dazu die Möglichkeiten des Linux Kernels 2.4 nutzen.


Weitere Begriffe

Memory Management, Linux

Ursache und Voraussetzungen

Mit dem Linux Kernel 2.2 muß das SAP System die User-Kontexte aller aktiven User gleichzeitig im Adressraum der Workprozesse eingeblendet halten. Das entspricht der klassischen UNIX-Implementierung des

Extended Memories (EM).


Die Summe aller gerade aktiven User-Kontexte ist damit durch die Adressraumbeschränkungen der Intel 32 Bit Plattform begrenzt. Konkret heißt das, daß maximal ca. 1,2 GB für alle User-Kontexte zusammen zur Verfügung stehen.


Lösung

Um mehr EM für die SAP User zur Verfügung zu stellen, bietet SAP auf der Basis des Linux Kernels 2.4 ab dem SAP Kernel 4.6D, Patchlevel 488, eine flexiblere EM Verwaltung.


Basierend auf dem TMP-Filesystem im Linux Kernel 2.4 kann der SAP Workprozess nun jeden gerade benötigten Userkontext einzeln in den Adressraum einblenden. Das bedeutet, daß nun ein einzelner Userkontext auf ca. 1,2 GB beschränkt ist. Die Summe der User-Kontexte kann jedoch bedeutend größer werden (im Prinzip nur begrenzt durch RAM + Swap). Dies ist völlig analog zum Memory Management unter Windows NT.


Sie können die neue EM-Verwaltung unter folgenden Voraussetzungen einsetzen:

1. Linux Kernel 2.4 mit dem TMPFS unter /dev/shm gemountet, s.u.

2. SAP Kernel 4.6D, Patchlevel 488 oder höher und

3. Im (Instanz-) Profil des SAP Applikationservers wird das oben beschriebene Verhalten aktiviert durch Setzung des Profilparameters: es/implementation = map


Weitere Parameter, die hier eine Rolle spielen, sind

em/max_size_MB (gibt die maximale Größe des EM an und sollte nicht so groß eingestellt werden, daß RAM + Swap erschöpft werden),
em/initial_size_MB (gibt die anfängliche Größe des EM an) und
em/address_space_MB (gibt die maximale Größe eines User-Kontexts an und wird bei Instanz-Start reserviert).


Falls die Linux-Distribution die passenden Einstellungen nicht

bereits setzt, können Sie auf der Betriebssystem-Ebene das TMPFS in folgender Weise einstellen:

4. Machen Sie folgenden Eintrag in das File /etc/fstab:

tmpfs /dev/shm tmpfs size=<size> 0 0


Die Angabe <size> sollten Sie entsprechend des verf&uuml;gbaren RAM + Swap einstellen. Wenn Ihre Maschine beispielsweise 4GB RAM und 8 GB Swap besitzt, so k&ouml;nnen Sie das TMPFS mittels

size=10G bzw. size=10240M

auf 10 Gigabyte begrenzen.

5. Mounten Sie das TMPFS:

mount /dev/shm

6. Pr&uuml;fen Sie, ob das unter /dev/shm gemountete TMPFS Platz meldet, damit die vorherigen Aktionen also gelungen sind:

df -h /dev/shm

Мда, давай-те я что-ли по русски скажу зачем нужна эта tmpfs

Поправьте если я ошибаюсь.

Компиляция gcc без -pipe либо mc-tarfs (konquieror-non-l):

Цикл такой: создание, запись, чтение, удаление.
Так вот, собственно данные должны записаться на диск, так как содержат измененные данные кэша файловой системы. Если это не успело произойти до стирания файла, ничего страшного они просто перейдут в разряд измененного буфера блочного устройства. Вообщем-то можно надеяться, что этот кусок диска перепишется новыми данными, если забыть об организации записи в ext2. (Диск раделен на несколько частей (inodes,data) которые заполняются равномерно (помере возможности), тоесть поочереди). Про журналируемые fs я просто промолчу :)

p.s. В solaris такая организация /tmp есть (не знаю на сколько давно), почему бы не использовать это в леинукс.

2oxonian
>Nakonec-ko Linuxoidy sdelali to, chto v tom zhe Solaris sushestvovalo uzhe davnym-davno :)

Во первых сделали давненько, года полтора назад.

Во вторых долго сомневались - стоит ли делать:
поскольку ext2 обгоняет tmpfs у Solaris на сравнимых
машинах ;P

Да и в солярке tmpfs появилась только из-за оооочень медленной
файловой системы.

>>Nakonec-ko Linuxoidy sdelali to, chto v tom zhe Solaris sushestvovalo uzhe davnym-davno :)
>
> Во первых сделали давненько, года полтора назад.
>
O! I pochemu tol'ko teper' etim stalo mozhno pol'zovat'sya? :)

> Во вторых долго сомневались - стоит ли делать:
> поскольку ext2 обгоняет tmpfs у Solaris на сравнимых
> машинах ;P
Ya ne razu benchmarki ne meryal, no dazhe pri "normal'nom" pol'zovanii
ya chto-to ni razu ne zamechal velikoj krutizny ext2 v tom chisle
i po skorosti.
>
> Да и в солярке tmpfs появилась только из-за оооочень медленной
> файловой системы.
nu konechno ufs tormoznee tmpfs, chto tut udivitel'nogo ?

2oxonian
>Ya ne razu benchmarki ne meryal, no dazhe pri "normal'nom" pol'zovanii

А на солярке работал ?

Ещё раз:
http://www.tux.org/lkml/#s9-12

Хммм ... а что если сделать ramdisk и на нем смонтировать /tmp ???

Все будет просто замечательно, окромя следуюших проблем:

1. Рамдиск забирает память у системы насовсем.
   В то время как тмпфс использует памятзь по потребности.

2. Размер рамдиска ограничен.
   тмпфс строго говоря тоже ограничен размерами физической памяти и свапа. параметр "size" указываемый команде mount ограничивает лишь
верхний предел.