Точки монтирования в режиме только для чтения

А можно ещё так:

mkdir /home/a mkdir /home/b mount --bind /home/a /home/b mount --bind /home/a /home/b mount --bind /home/a /home/b mount --bind /home/a /home/b mount --bind /home/a /home/b

делаем: 1. cat /etc/mtab 2. cat /proc/mounts 3. df

//rm -R /home/a

umount /home/b делаем: 1. cat /etc/mtab 2. cat /proc/mounts 3. df

И мне такой же травы!

Можно то же самое, но уложить в 2-3 осмысленных предложения?

> /tmp должен лежать в tmpfs, /dev - в udev

Насчет /tmp в tmpfs - это вы по созвучности слов? Или у вас памяти много?

> for i in bin boot etc lib opt sbin usr; do mount --bind -o ro "/$i" "/$i"; done

А толку, у тебя эти каталоги и так доступны на запись только для рута...

Лучше один раз попробовать, чем сто раз прочесть.

Вы же сами спрашивали, пробовал ли я. Ответ ДА, и вам рекомендую, чтобы ваши аргумента были более крепкими.

> Неа. Тем более что tmpfs всё равно в своп выдавливается.

http://www.uwsg.iu.edu/hypermail/linux/kernel/0612.0/1765.html чел пишет что скорость tmpfs при превышении памяти и сбросе в swap медленнее ext3

вот его raid: I can write (dd bs=1M if=/dev/zero of=file (20gb file)) about 180-200 mb/s. If I read the same file I get about 280mb/s throughput.

а вот его tmpfs в свапе: If the file size is > the physical memory (20gb, same test) I get a radically worsened total performance, on the write test it gets a throughput of 124mb/s. One would hope that it was faster than the ext3 test. One could guess that after the first 8gb it no longer fits into memory and the throughput gets many times slower. And all hell breaks loose when I try to dd that tmpfs file to /dev/null (bs=1M), it can only read at about ~20mb/s.

видимо это связано с фрагментированием swap и непредназначенностью tmpfs для больших файлов ?

> правда мода появится -- все что надо и не надо пихать в chroot-ы..

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

Вашу мааааать.....

Ёлки зелёные, я несколько лет уже этим "пользуюсь", и вдруг узнаю, что оно не работает.....

Это ж сколько раз я облажался...

> откуда едро узнает, что /etc лежит на другой FS, если fstab лежит не в "/", держать копию и пересинхронизироваться при выключении?

Ну подумай чуть-чуть - поймёшь, как это можно сделать. Но овчинка выделки не стоит. Можно и /bin да /sbin по отдельным разделам распихать, только зачем...

> Насчет /tmp в tmpfs - это вы по созвучности слов? Или у вас памяти много?

А вы поглядите, что в /tmp валяется. Пару метров tmpfs выделить для этой помойки из сокетов да lock-файлов и пусть оно хоть в своп проваливается, хоть не проваливается... У юзеров $HOME есть для своего барахла, у всяких демонов тоже.

> Это правильно конечно, но откуда едро узнает, что /etc лежит на другой FS, если fstab лежит не в "/", держать копию и пересинхронизироваться при выключении? ;)

не понял, а какая связь между ядром и fstab? про fstab знают только rc-скрипты

>> Насчет /tmp в tmpfs - это вы по созвучности слов? Или у вас памяти много? > А вы поглядите, что в /tmp валяется. Пару метров tmpfs выделить для этой помойки из сокетов да lock-файлов и пусть оно хоть в своп проваливается, хоть не проваливается... У юзеров $HOME есть для своего барахла, у всяких демонов тоже.

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

Мля, SELinux рулит :)

>Ёлки зелёные, я несколько лет уже этим "пользуюсь", и вдруг узнаю, что оно не работает.....

+1

Я ведь даже когда то проверял и всё даже, как мне показалось, работало (т.е. была защита от записи)

> не понял, а какая связь между ядром и fstab? про fstab знают только rc-скрипты

Дык /etc на отдельной партишне тоже нужно подмонтировать в древо, э? Чем и занимаются rc-скрипты.

Много лет использую tmpfs в качестве FS для /tmp.
Если не делать ln -s /var/tmp /tmp и не использовать mc для распаковки архивов ничего там не превышает.

alex@Outcast $ df -h /tmp
Файловая система Разм Исп Дост Исп% смонтирована на
tmpfs 443M 2,5M 440M 1% /tmp

> Насчет /tmp в tmpfs - это вы по созвучности слов? Или у вас памяти много?

tmpfs - она в виртуальной памяти, а не физической. Её размер может вообще превышать размер физической памяти, если свопа достаточно. Лично я делаю своп на пару гигов и /tmp на гиг. Работает нормально, даже при почти полном /tmp.

FreeBSD Forever! :) Тута можно без проблем монтировать корневой каталог только на чтение и менять режим на чтение и обратно на ходу :)

> Её размер может вообще превышать размер физической памяти, если свопа достаточно.

Ложь.

size:      The limit of allocated bytes for this tmpfs instance. The 
           default is half of your physical RAM without swap. If you
           oversize your tmpfs instances the machine will *deadlock*
           since the OOM handler will not be able to free that memory.

>FreeBSD Forever! :) Тута можно без проблем монтировать корневой каталог только на чтение и менять режим на чтение и обратно на ходу :)

А разве в linux-е так делать нельзя?!
Почему же тогда это работает?!
ИМХО вы батенько невкассу это сказали... так, поBSDеть немного.... :-/

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

А у всех всегда на / есть свободный гиг другой? У меня обычно нет.

>Если не делать ln -s /var/tmp /tmp и не использовать mc для распаковки архивов ничего там не превышает.

+1

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

Например?

telinit u не пробывали?

> а / - на ro
/ в ro - крайне неудобная вещь
такая же странная как и отдельный boot (конечно, если нет обстоятельств типа / на md)
/usr ro - одобрям
вообще, по моему мнению, / должна быть мимнимально работоспособной системой - то есть конечно не включать в себя полынй /usr и /var
но системный минимум для восставновления от сбоя - включать в себя,
как-то: /bin /sbin /lib /etc . Без этих каталогов - /boot зачастую бессмысленен. В то же время, разделение с usr var и прочими, позволяет уменьшить размер файлухи (=> снизить риски) и уменьшить объём backup или RAID1 для /.