вторая жизнь Supermount

> очевидный пример который делает такой подход неудобным -- отстегиваемые девайсы. вот воткнул я в комп кардридер, в него воткнул флешку. таки да, пришлось в fstab лезть потому что начиная с какой-то версии pmount отказывается что-либо монтировать без записи в fstab. а хотелось бы сразу..

Ну, повесьте HAL с fstab-sync'ом и каким-нибудь клиентом, который будет автоматом маунт дергать :-). В качестве примера такого клиента могу посоветовать KDE с medianotifier'ом и галочкой "Всегда выполнять это действие для данного типа устройств" :-).

Но, повторяю, для того, чтобы устроить автомонтирование (флэшек) достаточно коллбэка в /etc/dev.d/ и соответствующего правила в /etc/udev/...

Кстати, если на то пошло, то это _третья_ жизнь супермаунта. Первая началась в недрах мэндрэйксофта ;-).

> И шеллы/файлманагеры, открывшие диск, не дохнут от выдергивания?

С чего, Андрей?

Единственное, что при этом плохо - это то, что UDF'ные диски, используемые в режиме RW, так использовать нельзя. С другой стороны, я UDF'ные диски и не использую, пока хватает обычного CDRW и DVDRW :-). А cdrecord и growisofs (а может, это K3B заслуга? никогда не вникал) на время записи лочат привод самостоятельно, так что, кажется, опасность минимальна.

Очень хорошо.

Хотя я лично пользуюсь submount'ом, но пусть расцветают сто цветов.

Незаменима при работе с floppy. А всё остальное --- действительно ivman'ом ^_^

Я насчет истории ничего не знаю.

Насчет секьюрно - ты определись для всех хочешь монтировать или для одного. Ты просил для всех я сказал как.

В той же fc все работает через hal прекрасно без издевательств над ядром.

пожалуйста, подскажите поможет ли supermount решить задачу выезжания лотка DVD привода с диском при нажатии кнопки Eject (на самом приводе) во время воспроизведения фильма ?

Эту проблему поможет решить строчка

dev.cdrom.lock = 0

в /etc/sysctl.conf или, более подходяще, в /etc/udev/sysctl.conf, если udev в вашем дистрибутиве поддерживает установку параметров модулей (в большинстве не поддерживает, насколько мне известно).

Разумеется, после установления этого параметра надо запустить sysctl -p <путь до файла>/sysctl.conf

Вопрос, зачем уносить установку параметров модулей в udev, я оставлю для пытливого читателя ;-).

Вообще, как мне кажется в данный момент, supermount для "аккуратно записываемых" носителей не нужен (некоторое время назад вариант с sysctl'ем на cdrom казался мне ненадежным, но практика, кажется, свидетельствует об обратном).

ОК. По здравому размышлению, я соглашусь, что хорошо обученный рут справится создать конфигурацию с разумными правами для большинства типических случаев (в случае локального подключения, с сетевыми fs может быть сложнее, теоретицки). Пожалуй, единственная беда - нафиг не нужно беспокоить рута такой фигней, в 90% случаев;)

> В той же fc все работает через hal прекрасно без издевательств над ядром.

Вот! "через hal" - это важно. Фактически, hal дополняет классическую схему тем, что в нее "забыли" положить (в первую очередь, конечно, нотификация, а также всякая мета-информация про подключенное устройство и пр.). Из-за отсутствия стандатного подхода разные унихи реализовывали все эти фишки (объективно нужные) по-разному - поэтому гномовцам пришлось наваять hal, чтоб не создать линух-онли решение.

> Тому, чей клиент в интерактивном сеансе быстрее отозвался на ping по DBus'у ? ;-)

Шутка дня;) Кстати, тут пытался выяснить, как из системного демона (запущенного из init.d) доступиться к DBus десктопной сессии (ежели таковая есть). Не нашел конкретной инфы. Только невнятное бормотание на IRC, что так нельзя.

Не понимаю в чем проблема то? kde+hal+dbus+pmount - втыкаю все что угодно в самых разных вариациях, всегда монтируется и размонтируется прекрастно, в fstab про эти девайсы ничего нет. Что еще нужно то?

> С чего, Андрей?

Busy inodes on media change.

С супермаунтом, _кажется_, такого не было, если файлы не открыты.

C supermount'ом оно периодически (после сильных издевательств) говорило "Stale NFS link" :-).

В общем, что я могу сказать? Работает.

> Шутка дня;)

Рад, что понравилось :-)

> Только невнятное бормотание на IRC, что так нельзя.

Ну, нельзя-то, наверное, нельзя, но ежели очень хочется... В общем, просматривается по крайней мере, два варианта: рассылка оповещения (ну, это-то можно :-)) с последующим ожиданием, кто быстрее позовет маунт, и "рукопашная" пробежка по пользовательским сессионным демонам и подключение к ним, это ж суперюзер, ему все можно, он кем угодно может прикинуться... Хотя, согласен, варианты эти - скорее, чтобы доказать, что можно, а не что так делать правильно.

На деле же хватает простого отношения "центральный сервис" -> "пользовательские сервисы".

>Вот! "через hal" - это важно. Фактически, hal дополняет классическую схему тем, что в нее "забыли" положить (в первую очередь, конечно, нотификация, а также всякая мета-информация про подключенное устройство и пр.).

Ну да. Дык тут и овцы целы и волки сыты.

All я чего-то может и не понимаю, но чем не устраивает простой automount?

> чем не устраивает простой automount?

Автомаунт размонтирывает устройства только по истечению некого таймаута (или я ошибаюсь?), а если, к примеру, у мну 3 диска с музыкой, где чего -- не помню, и тут я хочу прослушать, скажем, альбом Арии "Химера" (весь), я всовываю блин в привод, захожу в папочку, автомаунт ее монтирует в этот момент, я смотрю -- нет, не он, и хочу вставить другой диск... По дефолту там минута (или две, не помню...) до размонтирования после последнего юзания. Так вот, мне нуна или ждать энти 1-2 мин, или поставить таймаут на 5 сек (что я сначала и сделал был). Но вот ХММС доигрывает композицию (перед этим закешированую) и приступает к следующей... Диск опять монтируется... И так десяток раз. Особенно рулит когда закешировалась только половина песни, и чтобы ее дослушать мне нада опять ждать монтирования.

Вот собственно этим и не устраивает.

У меня стоит моут на 30 сек, если ждать леняво umount ручками )

> У меня стоит моут на 30 сек

30 сек ситуацию не меняют -- композиция звучит 3-5 мин и занимает 3-5 метров, а значит кто-нибуть должен дергать привод каджые 500К, а в кеш обычно побольше помещается (особенно если ФС сильно не используется).

> если ждать леняво umount ручками )

Если б еще и моунт насильно можно было сделать чтоб не "отклеивался" потом :)

А я просто музыку с флэшек, дисков не слушаю )

> А я просто музыку с флэшек, дисков не слушаю )

А ты попробуй, тебе понравится :)

>>Эту проблему поможет решить строчка >>dev.cdrom.lock = 0

да, спасибо сработало. но не нарушит ли когда-нибудь стабильность моей системы этот метод ? (я к тому, что прибегать к нему пореже) лоток ведь выезжает, а диск то смонтирован в это время....

> Тому, чей клиент в интерактивном сеансе быстрее отозвался на ping по DBus'у ? ;-)

аукцион! :)

Есть еще submount <http://submount.sourceforge.net/>;. Компилится как модуль, распространяется отдельно от ядра. Но вот беда, последняя версия 0.9 из-за изменения API ядра больше не собирается и неизвестно будет ли апдейт. :( Мне тоже все эти, как тут было правильно подмечено dbus, hal, pmount, ivman, govna, piroga не нравятся. Во-первых, с точки зрения безопасности хреново когда что-то модифицирует /etc/fstab. Во-вторых, нахрен вся эта сложность?! Я просто хочу автомонтирование, вот и все. Не нравятся мне эти монстроидальные конструкции. В третьих, разве точка монтирования '/media' допускается стандартом FHS?

Во-первых (или в-последних), /media нынче - самый FHS, фыхаэснее не бывает.

Во-вторых, subfs - ну, не то, чтобы очень плохо, но от классических проблем automountd, равно как и subfs'а его так и не полечили - он по-прежнему не знает ничего про политики кэширования и т.п., занимаясь только монтированием (и размонтированием по таймауту).

В-третьих, "вся эта сложность" нужна для решения следующих задач:

1. Определить момент появления и исчезновения носителя в устройстве или устройства. Для этого заметную часть устройств (CD, _большинство_ кардридеров, как уверяли меня) надо поллить (увы, и ах, когда американские космические корабли уже вовсю бороздят межпланетное пространство...). Поллингом обязан заниматься демон, crond не предлагать :-)

2. Определение конфигурации вставленного устройства. Я сейчас, наверное, скажу крамолу, но мне в равном количестве попадались флэшки, отформатированные, как дискета (то есть, с разделом, видимым, как /dev/sd?) и как жесткий диск с единственным разделом (т.е. /dev/sd?1). Хуже того, как я уже говорил, я видел флэшки на которых был Mac'овый дисклэйбл и HFS, соответственно. Ну, и,помимо флэшек, бывают такие извращения, как подключаемые по USB и файрвайру жесткие диски и DVD-приводы (могу сфотографировать, ежели кто не верит и фотки выложить ;-)). И запускать каждый раз fdisk, пытаясь понять, что там на устройстве и как - просто влом.

3. "А еще я ею ем." такая связка позволяет ффтыкать (и, соответственно, детектить) и устройства, саффсем не подходящие под *storage, хотя и вполне подпадающие под режим "воткнул, попользовался, выдернул".

В-четвертых. Свзяка ivman и pmount, кажется, как раз и задумывалась для того, чтобы НЕ модифировать fstab. Ну, для параноиков. Но даром не нужно.

> но от классических проблем automountd, равно как и subfs'а Читать: autofs'а.

Не знаю. Наверное, какие-то приложения могут шизеть от такого, но большинство (все, используемые мною) переживают выдергивание из-под них файловой системы вполне мирно. Максимум, что выдается штатная ошибка о том, что файл или каталог более недоступен.

> Но вот беда, последняя версия 0.9 из-за изменения API ядра больше не собирается и неизвестно будет ли апдейт.

Патч элементарно гуглится. И всё работает.