[sisyphus] Про devfs, SCSI и не только

[sisyphus] Про devfs, SCSI и не только

[Alexey Morozov]

А что у нас с devfs'ом делается? В смысле, какова политика партии в 2.6 ядре, 
и почему бы нам не использовать его в std-up ядре?

Небольшая предыстория вопроса: я тут попытался написать нечто вроде 
"hotmount"-а - простенький по сути, но настраиваемый плагин для hotplug'а, 
который бы брал на себя функции [раз]монтирования hotpluggable устройств.  
Ну, чтобы, вставляя очередную флэшку, не искать судорожно,  куда она уехала 
сегодня.

Собственно, все замечательно, за исключением того, что я не вполне понимаю, 
как при традиционной методике именования дивайсов (/dev/sd*) можно 
гарантированно сопоставлять данные из /proc/scsi/scsi с именем в /dev/. То, 
что я увидал в исходниках updfstab (утилита из kudzu), повергло меня в легкий 
ужас. Воспроизводить ЭТО, да еще используя голимый bash - задача 
трудноразрешимая, и, кажется, довольно безумная. При использовании devfs 
задача сводится к тривиальной.

Кстати, поскольку мой опыт общения со скази-устройствами крайне скуден, вопрос 
вот еще какой: 

Всегда ли SCSI-эмуляционные модули (ну, такие как USB-storage, или там 
какие-нибудь другие, типа IDE-шных CDRW) выделяют под каждое новое устройство 
свой SCSI-хост? Или есть более сложные случаи, когда используются, 
предположим, Id'ы или, хуже того, Lun'ы? Пока, для USB-storage'ей все хорошо, 
но, возможно, где засада есть? :-)

P.S. а означенный hotmount, вроде, приближается к состоянию "works for me".
Если кому интересно, могу, после того, как выйду из отпуска, попробовать 
отдать на растерзание. Правда, поскольку "традиционное" монтирование мне не 
очень интересно ввиду использования supermount'а на флэшках, то, поначалу, 
видимо, какие-то части, вероятно, придется дописывать самим :-). Ну, или, по 
крайней мере, подробно рассказывать мне, чего хочется :-).
-- 
С уважением,
Алексей Морозов

Re: [sisyphus] Про devfs, SCSI и не только

[Serge Ryabchun]

On Wed, 23 Jul 2003, Alexey Morozov wrote:
> Всегда ли SCSI-эмуляционные модули (ну, такие как USB-storage, или там 
> какие-нибудь другие, типа IDE-шных CDRW) выделяют под каждое новое устройство 
> свой SCSI-хост? Или есть более сложные случаи, когда используются, 
> предположим, Id'ы или, хуже того, Lun'ы? Пока, для USB-storage'ей все хорошо, 
> но, возможно, где засада есть? :-)

# cat /proc/scsi/ide-scsi/0 
SCSI host adapter emulation for IDE ATAPI devices

# cat /proc/scsi/scsi 
Attached devices: 
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IOMEGA   Model: ZIP 100          Rev: 23.D
  Type:   Direct-Access                    ANSI SCSI revision: ffffffff
Host: scsi0 Channel: 00 Id: 01 Lun: 00
  Vendor: _NEC     Model: NR-7800B         Rev: 1.01
  Type:   CD-ROM                           ANSI SCSI revision: 02
  
только id разный, когда болтался еще один cdrom, то у него id был 02

-- 
Serge Ryabchun sr@osdn.org.ua

[sisyphus] Re: Про devfs, SCSI и не только

[Sergey Vlasov]

On Wed, 23 Jul 2003 14:28:42 +0700
Alexey Morozov <morozov@novosoft.ru> wrote:

> А что у нас с devfs'ом делается? В смысле, какова политика партии в 2.6 ядре, 
> и почему бы нам не использовать его в std-up ядре?

Были сведения, что в ядрах 2.4.x devfs работает ненадёжно.

> Небольшая предыстория вопроса: я тут попытался написать нечто вроде 
> "hotmount"-а - простенький по сути, но настраиваемый плагин для hotplug'а, 
> который бы брал на себя функции [раз]монтирования hotpluggable устройств.  
> Ну, чтобы, вставляя очередную флэшку, не искать судорожно,  куда она уехала 
> сегодня.
> 
> Собственно, все замечательно, за исключением того, что я не вполне понимаю, 
> как при традиционной методике именования дивайсов (/dev/sd*) можно 
> гарантированно сопоставлять данные из /proc/scsi/scsi с именем в /dev/.

В kernel-fix-drivers-scsi есть патч (07_scsi_proc_scsi_sd.patch),
который добавляет файл /proc/scsi/scsi_sd как раз с этой информацией в
следующем формате:

sprintf(page + len, "%s: scsi%02d(%d,%d,%d)\n", nbuff, sdp->host->host_no, sdp->channel, sdp->id, sdp->lun);

(nbuff - это имя sdX: sda/sdb/...)

[sisyphus] Re: Про devfs, SCSI и не только

[Alexey Morozov]

В сообщении от Четверг 24 Июль 2003 00:41 Andrey Borzenkov написал(a):
> On Wednesday 23 July 2003 11:28, Alexey Morozov wrote:
> > А что у нас с devfs'ом делается? В смысле, какова политика партии в 2.6
> > ядре, и почему бы нам не использовать его в std-up ядре?
>
> devfs входит в 2.6, по прежнему имеет статус EXPERIMENTAL и патриархи по
> прежнему вздыхают о ее замене но пока ее (замены) что-то не видать.
А что, все так плохо? А кто такой sysfs?

> Внутри devfs была довольно существенно урезана (я бы сказал -
> кастрирована), часть функциональности потерялась. Но в принципе я работаю
> на 2.6 с devfs не первый месяц и особых проблем (больше, чем в 2.4 :) не
> наблюдаю.
Понятно.

> задача неразрешима в 2.4 принципиально, в 2.6 на сегодняшний момент
> отсутствует (AFAIK) ее решение и devfs тут абсолютно не при чем.
В качестве локального решения существует (для 2.4, по крайней мере) патч на 
sd_mod (создающий /proc/scsi/scsi_sd с требуемым маппингом) и таки devfs, 
когда, определив SCSI-адрес вставленного устройства мы лезем к 
соответствующему дивайсу по адресу /dev/scsi/hostN/busN/.../disc. 
Ограниченно, конечно, но для данной задачи работает.

> В Linux до сих пор нет возможности определить постоянные логические адреса
> устройствам. Кто знает Solaris - если взять /etc/path_to_inst + devlinks
> убрать все те подводные камни которые там есть, то это примерно то, чего не
> хватает. Devfs только дает фиксированные адреса относительно контроллера -
> но вот адресация самих контроллеров только динамическая.
Понятно.


> В отдельных случаях (для SCSI, если есть строго по одному контроллеру
> данного типа) это решается с помощью scsi_hosts но в 2.6 поддержку этого
> параметра выкинули.

> ide-scsi эмулирует один HBA и все устройства получают SCSI ID, причем опять
> повлиять на них невозможно (год назад я сделал патч который присваивал ID в
> соответствии с IDE нумерацией, после IDE update он более не работал и у
> меня не было стимула заниматься им). Что касается LUN - я не встречал IDE
> устройства с несколькими LUNами хотя протокол позволяет.
Угу, спасибо, понял.

> Какая разница, как их нумеровать, если гарантируется, что после каждой
> перезагрузки устройства получают те же самые номера.
:-). Только пока мы не напарываемся на hot-pluggable устройства. У тех - "кто 
раньше встал, того и тапки".

> > P.S. а означенный hotmount, вроде, приближается к состоянию "works for
> > me". Если кому интересно, могу, после того, как выйду из отпуска,
> > попробовать отдать на растерзание. Правда, поскольку "традиционное"
> > монтирование мне не очень интересно ввиду использования supermount'а на
> > флэшках, то, поначалу, видимо, какие-то части, вероятно, придется
> > дописывать самим :-). Ну, или, по крайней мере, подробно рассказывать
> > мне, чего хочется :-).
> А вы не смотрели udev? Насколько я понимаю, он делает то-же самое - или
> нет?
Ну, сейчас нашел аннонс в lklm, прочитал, поглядел на код. Да, наверное, 
некоторое пересечение в функциональности есть. Однако, задача привязки 
вставленного [USB]-устройства к block-дивайсу для меня, скорее, промежуточная 
(и она вполне может в будущем решаться через udev). Я же хочу (в конечном 
итоге), чтобы вставленное устройство автоматически /становилось доступным/ по 
заранее известному адресу, и, соответственно, пользователь (моя супруга :-)) 
получала бы возможность простого доступа к данным, где-то в духе Windows XP 
(с появляющейся иконкой в Notification Area итд)

Плюс к тому, то, что я наваял - предельно просто. Собственно, функциональность 
про сопоставлению USB-storage и /dev/sdN или /dev/scsi/hostN/busN.../disc - 
~200-220 строчек pure bash-скрипта, даже без awk'а :-). Ну, и работает оно на 
стандартном (или почти стандартном) 2.4 ядре. Сейчас причешу функциональность 
по монтированию/размонтированию (а тут, видимо, придется таки воспользоваться 
внешними программами, типа parted'а), добавлю post-агентов, которые бы делали 
всякие глупости, типа той же нотификации, и буду использовать :-). Вот 
только,  может, еще поддержку subfs приделаю, чтобы, типа, поуниверсальнее 
было.
-- 
С уважением,
Алексей Морозов

Re: [sisyphus] Re: Про devfs, SCSI и не только

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

Sergey Vlasov пишет:
> On Wed, 23 Jul 2003 14:28:42 +0700
> Alexey Morozov <morozov@novosoft.ru> wrote:
> 
> 
>>А что у нас с devfs'ом делается? В смысле, какова политика партии в 2.6 ядре, 
>>и почему бы нам не использовать его в std-up ядре?
> 
> 
> Были сведения, что в ядрах 2.4.x devfs работает ненадёжно.
> 
> 
>>Небольшая предыстория вопроса: я тут попытался написать нечто вроде 
>>"hotmount"-а - простенький по сути, но настраиваемый плагин для hotplug'а, 
>>который бы брал на себя функции [раз]монтирования hotpluggable устройств.  
>>Ну, чтобы, вставляя очередную флэшку, не искать судорожно,  куда она уехала 
>>сегодня.
>>
>>Собственно, все замечательно, за исключением того, что я не вполне понимаю, 
>>как при традиционной методике именования дивайсов (/dev/sd*) можно 
>>гарантированно сопоставлять данные из /proc/scsi/scsi с именем в /dev/.
> 
> 
> В kernel-fix-drivers-scsi есть патч (07_scsi_proc_scsi_sd.patch),
> который добавляет файл /proc/scsi/scsi_sd как раз с этой информацией в
> следующем формате:
> 
> sprintf(page + len, "%s: scsi%02d(%d,%d,%d)\n", nbuff, sdp->host->host_no, sdp->channel, sdp->id, sdp->lun);
> 
> (nbuff - это имя sdX: sda/sdb/...)

Добавлю, что теперь это все никому не нужно. Достаточно просто вставить 
flash диск и сказать mount /mnt/flash[0-9]

Все это работает в текущем Sisyphus и Compact'е (альфа версии)

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [sisyphus] Re: Про devfs, SCSI и не только

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 5052 bytes --]

Alexey Morozov пишет:
> В сообщении от Четверг 24 Июль 2003 00:41 Andrey Borzenkov написал(a):
> 
>>On Wednesday 23 July 2003 11:28, Alexey Morozov wrote:
>>
>>>А что у нас с devfs'ом делается? В смысле, какова политика партии в 2.6
>>>ядре, и почему бы нам не использовать его в std-up ядре?
>>
>>devfs входит в 2.6, по прежнему имеет статус EXPERIMENTAL и патриархи по
>>прежнему вздыхают о ее замене но пока ее (замены) что-то не видать.
> 
> А что, все так плохо? А кто такой sysfs?
> 
> 
>>Внутри devfs была довольно существенно урезана (я бы сказал -
>>кастрирована), часть функциональности потерялась. Но в принципе я работаю
>>на 2.6 с devfs не первый месяц и особых проблем (больше, чем в 2.4 :) не
>>наблюдаю.
> 
> Понятно.
> 
> 
>>задача неразрешима в 2.4 принципиально, в 2.6 на сегодняшний момент
>>отсутствует (AFAIK) ее решение и devfs тут абсолютно не при чем.
> 
> В качестве локального решения существует (для 2.4, по крайней мере) патч на 
> sd_mod (создающий /proc/scsi/scsi_sd с требуемым маппингом) и таки devfs, 
> когда, определив SCSI-адрес вставленного устройства мы лезем к 
> соответствующему дивайсу по адресу /dev/scsi/hostN/busN/.../disc. 
> Ограниченно, конечно, но для данной задачи работает.
> 
> 
>>В Linux до сих пор нет возможности определить постоянные логические адреса
>>устройствам. Кто знает Solaris - если взять /etc/path_to_inst + devlinks
>>убрать все те подводные камни которые там есть, то это примерно то, чего не
>>хватает. Devfs только дает фиксированные адреса относительно контроллера -
>>но вот адресация самих контроллеров только динамическая.
> 
> Понятно.
> 
> 
> 
>>В отдельных случаях (для SCSI, если есть строго по одному контроллеру
>>данного типа) это решается с помощью scsi_hosts но в 2.6 поддержку этого
>>параметра выкинули.
> 
> 
>>ide-scsi эмулирует один HBA и все устройства получают SCSI ID, причем опять
>>повлиять на них невозможно (год назад я сделал патч который присваивал ID в
>>соответствии с IDE нумерацией, после IDE update он более не работал и у
>>меня не было стимула заниматься им). Что касается LUN - я не встречал IDE
>>устройства с несколькими LUNами хотя протокол позволяет.
> 
> Угу, спасибо, понял.
> 
> 
>>Какая разница, как их нумеровать, если гарантируется, что после каждой
>>перезагрузки устройства получают те же самые номера.
> 
> :-). Только пока мы не напарываемся на hot-pluggable устройства. У тех - "кто 
> раньше встал, того и тапки".
> 
> 
>>>P.S. а означенный hotmount, вроде, приближается к состоянию "works for
>>>me". Если кому интересно, могу, после того, как выйду из отпуска,
>>>попробовать отдать на растерзание. Правда, поскольку "традиционное"
>>>монтирование мне не очень интересно ввиду использования supermount'а на
>>>флэшках, то, поначалу, видимо, какие-то части, вероятно, придется
>>>дописывать самим :-). Ну, или, по крайней мере, подробно рассказывать
>>>мне, чего хочется :-).
>>
>>А вы не смотрели udev? Насколько я понимаю, он делает то-же самое - или
>>нет?
> 
> Ну, сейчас нашел аннонс в lklm, прочитал, поглядел на код. Да, наверное, 
> некоторое пересечение в функциональности есть. Однако, задача привязки 
> вставленного [USB]-устройства к block-дивайсу для меня, скорее, промежуточная 
> (и она вполне может в будущем решаться через udev). Я же хочу (в конечном 
> итоге), чтобы вставленное устройство автоматически /становилось доступным/ по 
> заранее известному адресу, и, соответственно, пользователь (моя супруга :-)) 
> получала бы возможность простого доступа к данным, где-то в духе Windows XP 
> (с появляющейся иконкой в Notification Area итд)
> 
> Плюс к тому, то, что я наваял - предельно просто. Собственно, функциональность 
> про сопоставлению USB-storage и /dev/sdN или /dev/scsi/hostN/busN.../disc - 
> ~200-220 строчек pure bash-скрипта, даже без awk'а :-). Ну, и работает оно на 
> стандартном (или почти стандартном) 2.4 ядре. Сейчас причешу функциональность 
> по монтированию/размонтированию (а тут, видимо, придется таки воспользоваться 
> внешними программами, типа parted'а), добавлю post-агентов, которые бы делали 
> всякие глупости, типа той же нотификации, и буду использовать :-). Вот 
> только,  может, еще поддержку subfs приделаю, чтобы, типа, поуниверсальнее 
> было.

Может быть все-таки сначала стоит воспользоваться тем, что реализовано? 
А именно - обновить систему до последнего sisyphus и вставить flash 
диск. В случае с KDE - говорят даже иконка на рабочем столе появляется ;-)

В остальных же случаях - mount /mnt/flash

Ну а размонтируется она сама, при вынимании flash'ки из USB... автоматом.

Сделано это так: hotplug стартует updfstab из kudzu, который для 
различного рода устройств может делать различного рода маунтпойнты и 
записи в fstab вносить... Антон Качалов довел его до рабочего состояния 
(с моей помощью небольшой), ну и се	йчас все это функционирует просто на 
"Ура".

А патч на sd наверное можно убрать из пакета... в принципе, если очень 
надо - можно написать небольшую C-шную утилитку, рассказывающую о том, 
какие все-таки девайсы появились.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [sisyphus] Про devfs, SCSI и не только

[Alexey Morozov]

В сообщении от Среда 30 Июль 2003 12:21 Anton Farygin написал(a):
> Добавлю, что теперь это все никому не нужно. Достаточно просто вставить
> flash диск и сказать mount /mnt/flash[0-9]
> Все это работает в текущем Sisyphus и Compact'е (альфа версии)
И как это работает? updfstab из kudzu-1.1.9-alt2 не предлагать (то есть, у 
меня он и стоит, для решения поставленной задачи он не подходит).

И, как я уже говорил, есть настойчивое желание обойтись без

mount /mnt/flash0 || mount /mnt/flash1 || mount /mnt/flash2 ... <и так пока не 
найдется, куда его засунули>

А, кроме того, у меня, кроме двух флэшек сейчас в доступности появятся 
compact-flash и некий десятигиговый USB-харддрайв, на котором может быть 
сильно больше 1 FAT раздела (это как хозяину винта запотемится). Так что, 
количество возможных мест и  опций монтирования вырастает, эдак, раз в 
несколько...

Кроме того, мне совершенно неохота думать над размонтированием устройства, 
когда я его вытаскиваю. Я попробовал, /с некоторой вероятностью/  у меня 
возникает следующая ситуация с "втыканием/вытыканием":

1. вставляем флэшку
2. открываем шелл
3. mount /dev/sda1
4. cd /mnt/flash
5. вынимаем флэшку
6. открываем еще один шелл, убеждаемся, что /dev/sda1 отмонтировался (при этом 
шелл с PWD=/mnt/flash до сих пор запущен)
7. вставляем флэшку
8. при попытке снова сказать /dev/sda1 mount уходит в аут (в смысле, теряется 
в ядреных потрохах). Ядро - std-up. Сейчас дотащу последнее alt6, может, там 
что поменялось... Дотащил, да, теперь вроде отрабатывает нормально, сейчас 
буду смотреть, что поменялось, и почему раньше не работало. А оптимальнее 
всего, конечно, использовать supermount/subfs, но updfstab не настраивается.

Да, кстати, вот еще жалобы на updfstab (kudzu-1.1.9-alt2):

после вставления флэшки (A-data'вский "Speed Drive" на 256 Mb) оно мне внесло 
в fstab вот такую строчку:

/dev/sda                /mnt/flash              auto    
noauto,user,kudzu,sync,noexec,nodev,nosuid,iocharset=koi8-r 0 0

Меня это не устраивает, по меньшей мере, по трем причинам.

1. На /dev/sda данной флэшки - никаких "пользовательских" данных, раздел с 
данными (VFAT) находится на первом разделе. В предыдущей версии в 
updfstab.conf.default для этих дивайсов указывалось, что нужно использовать 
partition 1, а вообще, по-хорошему, это надо детектить (н-р, при помощи 
parted'а)

2. Файлы на смонтированной таким образом FS получают права 0700, а возможности 
указать особые опции монтирования для дивайса, в общем, нет. 

3. Где драйв окажется в следующий раз,  и что будет, если количество партиций 
окажется больше/меньше, чем описано в updfstab.conf

В общем, конечно, можно пытаться хачить updfstab. Но как я уже говорил, 
написан он внутри, э-э-э, довольно пугающе (и, зачем-то, целиком на C), и, 
поскольку вся [не]функциональность немаленькой в общем программы укладывается 
в <300 строчек bash-скрипта, мне проще сразу сделать, как [мне] будет удобно.
-- 
С уважением,
Алексей Морозов

Re: [sisyphus] Про devfs, SCSI и не только

[Sergey S. Skulachenko]

On Wed, 30 Jul 2003 09:33:25 +0400
Anton Farygin <rider@altlinux.com> wrote:

> Может быть все-таки сначала стоит воспользоваться тем, что
> реализовано? А именно - обновить систему до последнего sisyphus
> и вставить flash диск. В случае с KDE - говорят даже иконка на
> рабочем столе появляется ;-)

Точно, появляется, и даже работает. Сейчас вставил в нижний слот
flash reader'а карточку SD и смонтировал ее с помощью одной из
"иконок". Заглянул в /mnt/flash1 - все правильно. Приятно!

_____________
С уважением,
С.С.Скулаченко

Re: [sisyphus] Про devfs, SCSI и не только

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 3975 bytes --]

Alexey Morozov пишет:
> В сообщении от Среда 30 Июль 2003 12:21 Anton Farygin написал(a):
> 
>>Добавлю, что теперь это все никому не нужно. Достаточно просто вставить
>>flash диск и сказать mount /mnt/flash[0-9]
>>Все это работает в текущем Sisyphus и Compact'е (альфа версии)
> 
> И как это работает? updfstab из kudzu-1.1.9-alt2 не предлагать (то есть, у 
> меня он и стоит, для решения поставленной задачи он не подходит).

Почему ?

> 
> И, как я уже говорил, есть настойчивое желание обойтись без
> 
> mount /mnt/flash0 || mount /mnt/flash1 || mount /mnt/flash2 ... <и так пока не 
> найдется, куда его засунули>

Ага.. понятно. Тогда есть еще одно решение, но оно не менее неприятное: 
devlabel

Работает по следующему принципу:

1) Вставляем флэшку
2) говорим devlabel add на /dev/sd<что-то там>
3) вынимаем флешку
4) Вставляем ее снова
5) Говорим devlabel restart - наблюдаем автоопределение flash'ки и 
созданный симлинк в /dev/ (имя симлинка задается заранее, при devlabel add)

В общем - тоже криво.. я бы даже сказал - кривее чем updfstab

> 
> А, кроме того, у меня, кроме двух флэшек сейчас в доступности появятся 
> compact-flash и некий десятигиговый USB-харддрайв, на котором может быть 
> сильно больше 1 FAT раздела (это как хозяину винта запотемится). Так что, 
> количество возможных мест и  опций монтирования вырастает, эдак, раз в 
> несколько...

Тут нужно просто придумать удобную схему расположения маунтпойнтов. Не 
более того.

> 
> Кроме того, мне совершенно неохота думать над размонтированием устройства, 
> когда я его вытаскиваю. Я попробовал, /с некоторой вероятностью/  у меня 
> возникает следующая ситуация с "втыканием/вытыканием":

При вытаскивании флешки запускается umount -l на нее. Должно 
_гарантированно_ размонтировать.

> 
> 1. вставляем флэшку
> 2. открываем шелл
> 3. mount /dev/sda1
> 4. cd /mnt/flash
> 5. вынимаем флэшку
> 6. открываем еще один шелл, убеждаемся, что /dev/sda1 отмонтировался (при этом 
> шелл с PWD=/mnt/flash до сих пор запущен)
> 7. вставляем флэшку
> 8. при попытке снова сказать /dev/sda1 mount уходит в аут (в смысле, теряется 
> в ядреных потрохах). Ядро - std-up. Сейчас дотащу последнее alt6, может, там 
> что поменялось... Дотащил, да, теперь вроде отрабатывает нормально, сейчас 
> буду смотреть, что поменялось, и почему раньше не работало. А оптимальнее 
> всего, конечно, использовать supermount/subfs, но updfstab не настраивается.

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

> 
> Да, кстати, вот еще жалобы на updfstab (kudzu-1.1.9-alt2):
> 
> после вставления флэшки (A-data'вский "Speed Drive" на 256 Mb) оно мне внесло 
> в fstab вот такую строчку:
> 
> /dev/sda                /mnt/flash              auto    
> noauto,user,kudzu,sync,noexec,nodev,nosuid,iocharset=koi8-r 0 0
> 
> Меня это не устраивает, по меньшей мере, по трем причинам.
> 
> 1. На /dev/sda данной флэшки - никаких "пользовательских" данных, раздел с 
> данными (VFAT) находится на первом разделе. В предыдущей версии в 
> updfstab.conf.default для этих дивайсов указывалось, что нужно использовать 
> partition 1, а вообще, по-хорошему, это надо детектить (н-р, при помощи 
> parted'а)
> 
> 2. Файлы на смонтированной таким образом FS получают права 0700, а возможности 
> указать особые опции монтирования для дивайса, в общем, нет. 
> 
> 3. Где драйв окажется в следующий раз,  и что будет, если количество партиций 
> окажется больше/меньше, чем описано в updfstab.conf

Это Race. Я даже знаю как ее исправлять, но там на пару дней работы.

> 
> В общем, конечно, можно пытаться хачить updfstab. Но как я уже говорил, 
> написан он внутри, э-э-э, довольно пугающе (и, зачем-то, целиком на C), и, 
> поскольку вся [не]функциональность немаленькой в общем программы укладывается 
> в <300 строчек bash-скрипта, мне проще сразу сделать, как [мне] будет удобно.

Ок. Как будет готово - я могу посмотреть то, что получится на предмет 
замены updfstab.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]