В последних версиях прошивки Олега было сделано много усилий, чтобы сделать процесс загрузки более прозрачным. В частности в версии 1.9.2.7-8.7 появился новый файл --- pre-mount. На мой взгляд поддержка fstab не отражена в имеющихся основных тьториалах по первичной настройке, а она дает очень гибкий и мощный инструмент для осмысленного управления дисковой подсистемой. К тому же, в новых прошивках эти файлы стали чрезвычайно лаконичными и я бы даже сказал изящными 
Сразу отмечу, что настройку post-firewall здесь рассматривать не буду.
Кроме того, на мой взгляд --- эта тема не тьюториал для начинающих, а скорее предложение квалифицированной части форума обсудить оптимальный вид этих файлов применительно к новым прошивкам. Тем не менее я постарался разжевать тему максимально подробно, чтобы она могла быть источником информации для всех интересующихся. Буду стараться обновлять материал по мере поступления обратной связи.
Итак, после проведенного на днях апгрейда hdd мой /etc/fstab выглядит таким образом:
PHP Code:
#device Mountpoint FStype Options Dump Pass#
/dev/discs/disc0/part1 none swap sw 0 0
/dev/discs/disc0/part2 /opt ext3 rw,noatime 1 1
/dev/discs/disc0/part3 /opt/home ext3 rw,noatime 1 1
/dev/discs/disc0/part4 /home ext3 rw,noatime 1 1
/dev/discs/disc1/part2 /mnt ext3 rw,noatime 1 1
К счастью, по крайней мере в моем 2 диска, подключенные через внешний USB2 hub определяются всегда в одном и том же порядке, так что /etc/fstab --- это просто статический файл.
Идея разбиения на несколько разделов такова:
/opt --- программы
/home --- архив
/opt/home --- файловая система для текущих закачек и т.д.
/mnt --- прежний винчестер, который со временем будет удален
В идеале надо было бы добавить отдельную файловую систему /var (или /opt/var) и сделать доступ к /opt только для чтения, но это наверное буду пробовать теперь уже при следующем апгрейде. Наиболее рискованная ф.с. с точки зрения потенциальной потери данных --- /opt/home (потому она и вынесена в отдельный раздел не очень большого размера). По завершении закачек файлы из этого раздела планируется перемещать в /home , а если необходимо что-то расшарить, то создать симлинки.
[Замечание: если Вы планируете использовать /opt/home в качестве точки монтирования как это написано у меня, то не забудьте ее создать: mkdir /opt/home ]
Первый опыт, который давно напрашивался и стал легко возможным с появлением файла pre-mount без уродливого принудительного размонтирования автосмонтированных дисков --- автоматическая проверка файловых систем при перезагрузке.
Рекомендуемый на данный момент вариант файла pre-mount выглядит так:
PHP Code:
#! /bin/sh
swapon -a
for i in `/usr/bin/awk '/ext3/{print($1)}' /etc/fstab`
do
/bin/grep -q $i /proc/mounts || /sbin/e2fsck -p $i 2>&1 | /usr/bin/logger -t e2fsck
done
Здесь на основе /etc/fstab формируется список имеющихся ф.с. и они по очереди проверяются.
Итак, что же мы получаем при загрузке если мы выполняем подобную проверку после обыкновенной перезагрузки. Для этого смотрим в syslog и видим примерно следующее (здесь приведена картинка для старой версии, но результат в syslog.log должен выглядеть подобным образом:
PHP Code:
/dev/discs/disc0/part2: recovering journal
/dev/discs/disc0/part2: clean, 15942/245280 files, 102559/489982 blocks (check after next mount)
/dev/discs/disc0/part3: recovering journal
/dev/discs/disc0/part3: clean, 5141/1835008 files, 1148511/3664828 blocks (check in 5 mounts)
/dev/discs/disc0/part4: recovering journal
/dev/discs/disc0/part4: clean, 73/12517376 files, 3719155/25023245 blocks (check after next mount)
/dev/discs/disc1/part2: recovering journal
/dev/discs/disc1/part2: clean, 36785/2431680 files, 341863/4857654 blocks (check in 2 mounts)
Интересное наблюдение, что все файловые системы при перезагрузке оказались не совсем в порядке. Скорее всего, повреждения минимальны, но все равно как то неприятно. Однако ведь у нас есть файл pre-shutdown.
Необходимо отметить, что размонтировать файловую систему, при запущенных многих процессах в памяти очень трудно, либо невозможно. Однако, можно легко перемонтировать в состояние read-only.
У меня не получились следующие действия:
mount -a -r
mount -a -o remount,ro
mount -t ext3 -r
mount -t ext3 -o remount,ro
Однако, перемонтирование ф.с. по одной работает без проблем, а ведь у нас есть полный список в файле /etc/fstab ! Заодно отключим и swap
У меня файл pre-shutdown вышел таким ( более свежая версия от 2/2009 описана здесь: http://www.wl500g.info/showpost.php?...3&postcount=37 ):
PHP Code:
#! /bin/sh
/opt/etc/init.d/rc.unslung stop
for i in `awk '/ext3/{print($1)}' /etc/fstab`
do
mount -o remount,ro $i
done
swapoff -a
sleep 5s
Результат ---
PHP Code:
/dev/discs/disc0/part2: clean, 15949/245280 files, 102570/489982 blocks
/dev/discs/disc0/part3: clean, 5134/1835008 files, 117343/3664828 blocks (check in 3 mounts)
/dev/discs/disc0/part4: clean, 1320/12517376 files, 5471367/25023245 blocks
/dev/discs/disc1/part2 has been mounted 39 times without being checked, check forced.
/dev/discs/disc1/part2: 36782/2431680 files (7.5% non-contiguous), 341863/4857654 blocks
Выглядит гораздо приятнее --- все файловые системы чистые. Надо отметить, что особенностью файловых систем unix является то, что в них имеется счетчик числа монтирований, который выполняет принудительную проверку состояния ф.с. после определенного числа монтирований даже "чистой" ф.с. Таким образом, в приведенном примере на ф.с. /dev/discs/disc1/part2 была проведена принудительная проверка, которая затянула загрузку минуты на 2-3. Однако, как известно чистота --- залог здоровья и ИМХО вполне допустимо иногда иметь долгие загрузки, однако иметь больше уверенности в целостности данных.
Теперь насчет файла rc.unslung, который также задействован в файле pre-shutdown. Цивилизованный запуск демонов с диска традиционно производится путем вызова из post-boot файла /opt/etc/init.d/rc.unslung , который в свою очередь запускал все файлы в директории /opt/etc/init.d , которые начинались с заглавной буквы S . Эти файлы туда устанавливались инсталляторами приложений, либо могли быть добавлены вручную. Однако, если запуск производится стандартизованным путем, то почему же остановку запущенных демонов не производить также цивилизованным путем, т.е. через тот же rc.unslung (причем еще и в обратном порядке, чтобы S01syslogd был прибит последним и процесс отключения процессов был бы запротоколирован)? Как минимум для rtorrent такое отключение просто чрезвычайно полезно, т.к. если его отрубать без предупреждения, то он не успевает цивилизованно отключиться от треккера и после следующего включения надсадно хеширует все имеющиеся файлы. Некоторые файлы S??* пришлось подредактировавть, чтобы заставить их принимать стандартные аргументы start|stop.
В общем обновленный /opt/etc/init.d/rc/unslung , который теперь принимает один параметр --- либо start либо stop у меня вышел таким:
PHP Code:
#! /bin/sh
# Start/stop all init scripts in /opt/etc/init.d
# starting them in numerical order and
# stopping them in reverse numerical order
#
if [ $# -ne 1 ]; then
printf "Usage: $0 {start|stop}\n" >&2
exit 1
fi
daemons=`echo $(/usr/bin/dirname $0)/S??*`
[ $1 = "stop" ] && daemons=`echo $daemons | /usr/bin/tr " " "\n" | /usr/bin/sort -r`
for i in $daemons; do
# Ignore dangling symlinks (if any).
[ ! -f "$i" ] && continue
case "$i" in
*.sh)
# Source shell script for speed.
(
trap - INT QUIT TSTP
set $1
. $i
)
;;
*)
# No sh extension, so fork subprocess.
$i $1
;;
esac
done
На мой взгляд теперь более подходящее место для запуска этих демонов --- файл post-mount:
PHP Code:
#! /bin/sh
/opt/etc/init.d/rc.unslung start
А post-boot у меня стал тоже чрезвычайно изящным:
PHP Code:
#! /bin/sh
dropbear
Остался неосвещенным еще файл pre-boot. В нем у меня запускается ipt_recent, который используется для контроля доступа к ssh порту из wan (в последней прошивке этот модуль также прописался во внутренней флеши):
PHP Code:
#! /bin/sh
#Both these lines are required/recommended for protection against unwanted multiple ssh logins based on ipt_recent ( http://wl500g.info/showpost.php?p=69660&postcount=53 )
#date 010101012000
#insmod /usr/local/lib/ipt_recent.o
insmod ipt_recent
Система получилась вроде довольно стройная и я решил поделиться ею с остальными членами нашего Клуба в надежде, что для кого то это может оказаться полезной информацией, а кто-то сможет сделать полезные предложения по ее улучшению.
Forum Guru
Размышления об использовании файлов pre-* и post-* в новых прошивках Олега
Originally Posted by al37919
Posting Permissions
