On 2006.03.01 at 01:40:38 +0300, Mikhail Ramendik wrote: > > Здесь по крайней мере вызывается umount, пусть на уже вытащенный диск. > > Однако если хоть один процесс его держит, umount, если я правильно понимаю, > просто не сработает :( А если не держит - так через таймаут (скажем, 3 > секунды) autofs тоже сделает размонтирование.
Насколько я понимаю, если файловая система уже недоступна, то ядро в этом случае ведет себя немножко по-другому. Опять же ключик -f у umount есть. > > А по хорошему, по событию eject надо запускать fuser -m и прибивать все > > процессы, использующие данную fs > > А вот этого я бы точно не делал. Зачем убивать файломенеджеры и шеллы, > которые > в этот момент смотрят на диск? Они ведь и так отнюдь не падают. Ради редких > падающих/виснущих процессов убивать все? Затем что если ты вытаскиваешь диск, то shell у которого CWD на этом диске тебе уже не нужен. shell-ы это вообще расходный материал - для каждого скрипта новая копия запускается. А если у тебя есть файлменеджер, который держит директорию на съемном носителе, и не отрабатывает корректно сигнал, то такой файлменеджер убивать надо не сигналом а aptitude remove. Собственно есть две ситуации: 1. Мелкая (в стиле unix-way) программа, которая была запущена специально для работы с данными на этом диске. А потом просто пользователь забыл её закрыть. Тогда прибивание программы по событию вытаскивания диска - нормальное явление. Юзер не закрыл - система для него закроет. 2. Программа, которую убивать вообще-то жалко, но из-за того что программист головой не подумал, она не отпускает диск вовремя. В этом случае посылка сигнала делает тайный глюк (который имеет шансы проявиться, если вдруг программа обратится к неотпущенному ресурсу) явным. Нечто вроде electric fence, non-executable stack и прочих подобных средств отладки и защиты. В данном случае падение программы при вытаскивании диска делает просто более заметным факт, что эта программа с диском неаккуратно обращается. И, следовательно, должна быть либо исправлена, либо заменена на более правильную. > Мне кажется, что правильно было бы сделать некую proxy file system (на fuse, > вероятно, чтобы в ядро не лезть лишний раз), которая будет работать через > обычную FS, но корректно отрабатывать её пропадание в любой момент (т.е. не > зависать, а fail'иться). Однако я такое вряд ли в состоянии написать :( А Лично я не понимаю какая нафиг разница между fail-ящимся системным вызовом и прилетающим сигналом. И то, и другое может быть программой обработано. И то, и другое по умолчанию приводит к падению программы. В данном случае реализация особой ситуации посредством посылки сигнала обходится намного проще чем реализация её посредством возврата ошибки из системного вызова. > Я бы рад сменить, скажем, shell на такой, который не держит за хвост свою > текущую директорию, а открывает её только при подаче команды... (Правда, я и Для shell-а это как раз не имеет смысла. Прибил его и дело с концом. У него внутреннего состояния практически нет, кроме той самой CWD. Переменные среды, определенные только для данного shell - большая редкость. Беречь имеет смысл программы, у которых есть внутреннее состояние. Скажем, текстовый редактор с открытым и модифицированным файлом. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
