суббота, 5 сентября 2009 г.

FreeBSD: Automount

Известная проблема непривелегированного использования съёмных носителей с неродными файловыми системами с использованиеванием таблиц перекодирования символов (mount_msdosfs: msdosfs_iconv: Operation not permitted) под FreeBSD может быть решена, собственно, самой системой.

Как это есть


Обычный сценарий использования съёмного носителя под операционными системами класса Unix заключается в следующем:
  1. Подсоединить устройство с носителем к внешнему интерфейсу (USB, SAS, FireWire).
  2. Создать каталог-точку монтирования (если каталог не создан заранее).
  3. Смонтировать сменный носитель в каталог-точку монтирования с опциями по перекодированию символов неродной файловой системы в родную файловую систему и обратно.
  4. Поработать с файловой системой носителя.
  5. Демонтировать сменный носитель.
  6. Отсоединить устройство.

Все эти действия пользователь выполняет без какой-либо автоматизации, вручную!

В отличие от вездесущего Linux-демона HAL, работающего в связке с PolicyKit и демоном информационной шины D-Bus, встроенные системные средства FreeBSD позволяют обойтись без нагромождений стороннего софта. Естественно, модуль конвертации кодировок msdosfs_iconv из одной системы в другую и обратно всё же должен быть прописан в автозагрузке в файле /boot/loader.conf (msdosfs_iconv_enable="YES"), либо вкомпилирован в ядро системы (options MSDOSFS_ICONV).

"Всё должно быть просто, но не так чтобы сильно." © кто-то из великих

Преамбула


Только хозяин (owner, создатель) каталога может производить в него монтирование устройств, работать с файловой системой смонтированого устройства как ему вздумается. Демон devd(8) (device state change daemon) работает с системной (root) учётной записью и у него нет понятия "текущий пользователь" (строго говоря, FreeBSD — это многопользовательская ОС, в которой одновременно работают различные процессы под разными учётными записями). В общем, демон devd(8) имеет понятие только об устройствах (классах устройств) виртуальной файловой системы devfs(8), файловой системе вообще и событиях, случающихся в системе, но не имеет понятия, какой пользователь подсоединил или отсоединил девайс.

Фокус-покус


Хорошая новость: FreeBSD больше не падает при отсоединении неотмонтированной флэшки. А именно это будет происходить всякий раз, при использовании следующего описания. Хотя и не страшно.

Пишем в /etc/devd.conf следующие строчки:

# Automount
attach 10 {
match "device-name" "umass[0-9]+";
action "sleep 4 && mkdir -p /media/$device-name && chown -R username /media/$device-name && \
(/sbin/mount_msdosfs -o sync -L ru_RU.UTF-8 -D CP1251 /dev/da0s1 /media/$device-name || \
/sbin/mount_msdosfs -o sync -L ru_RU.UTF-8 -D CP1251 /dev/da0 /media/$device-name)";
};
detach 10 {
match "device-name" "umass[0-9]+";
action "/sbin/umount -f /media/$device-name && rm -r /media/$device-name";
};

Запускаем демон состояния виртуальной файловой системы устройств:
% echo 'devd_enable="YES"' >> /etc/rc.conf
% /etc/rc.d/devd start

Или рестартуем его, если он работает (чтобы он перечитал свой конфиг):
% /etc/rc.d/devd restart
Stopping devd.
Starting devd.

На события attach/detach демон devd(8) реагирует следующим образом: определяет, какой тип устройства подключается/отключается (здесь: umassНомерустройства) и совершает соответствующее действие (action). Из описанных действий нетрудно понять, каким образом ведётся работа с флэшкой.

При подсоединении съёмного носителя (флэшки) будет создан каталог /media/umass0, носитель будет подвергнут проверке fsck и, если никаких ошибок не найдено, созданный каталог изменит владельца на username, и в этот каталог смонтируется устройство /dev/da0s1 (первый слайс накопителя с файловой системой FAT). После этого пользователь, имеющий учётную запись username, сможет работать с устройством как с собственным файловым хранилищем.

Так как устройство работает в синхронном режиме, то есть данные на носитель пишутся и читаются последовательно, без отложенных операций, то ручное отмонтирование не требуется — по завершении всех операций достаточно просто отсоединить устройство — это событие заставит демон devd(8) выполнить действия по очистке точки монтирования, как в виртуальной файловой системе devfs (демонтирует каталог /dev/da0s1), так и в реальной файловой системе (удалит временный каталог /media/umass0).

Три ложечки дёгтя


  1. Необходимость в использовании имени учётной записи пользователя (username), к которому привязывается точка монтирования;
  2. Фиксированное название раздела носителя (da0s1) не позволит смонтировать в автоматическом режиме другие носители;
  3. Фиксированный тип файловой системы (msdosfs) на монтируемом носителе не позволяет правилом attach смонтировать носитель, с тем же названием раздела, но с отличной от FAT ФС.


P.S.


Я имею представление о портах, позволяющих обходить проблему автомонтирования флэшек с разных сторон: sysutils/kiconvtool и sysutils/automounter. Но лично у меня первый порт не заработал (ошибка осталась), а второй несколько избыточен по функциональности (надстройка над amd(8)).

четверг, 13 августа 2009 г.

Diablo JDK 1.6: ошибка в VM

Информация о системе


> uname -rsm
FreeBSD 8.0-BETA2 amd64
Дерево портов обновлено.

Инсталляция и неудачный запуск


% portinstall -p java/diablo-jdk16
...
===> Registering installation for diablo-jdk-1.6.0.07.02_5
...
===> Building package for diablo-jdk-1.6.0.07.02_5
...
===> Cleaning for diablo-jdk-1.6.0.07.02_5
---> Cleaning out obsolete shared libraries
[Updating the pkgdb in /var/db/pkg ... - 444 packages found (-0 +1) . done]
% rehash
% java -version
Error occurred during initialization of VM
Unable to load ZIP library: /usr/local/diablo-jdk1.6.0/jre/lib/amd64/libzip.so
%

Решение проблемы

% echo "libz.so.4 libz.so.5 #for diablo-jdk1.6" >> /etc/libmap.conf
% rehash
% java -version
Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
Diablo Java HotSpot(TM) 64-Bit Server VM (build 10.0-b23, mixed mode)
%

среда, 12 августа 2009 г.

Метки GPT для ZFS

Нужно создать ZFS пул с зеркалом из носителей, смонтированных по меткам GPT, чтобы не зависеть от имён устройств и номеров портов контроллёров.

Исходное состояние


Зеркало как таковое отсутствует:

% zpool status
pool: amd64rio
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
amd64rio ONLINE 0 0 0
ad6p3 ONLINE 0 0 0

errors: No known data errors

Включим в пул ещё один носитель (GPT-раздел устройства ad10) — разметка разделов второго винчестера аналогична первому, так что здесь последовательность команд не приводится.

Создание зеркала в пуле


% zpool attach amd64rio /dev/ad6p3 /dev/ad10p3
% zpool scrub amd64rio
% zpool status
pool: amd64rio
state: ONLINE
scrub: scrub in progress for 0h0m, 0,00% done, 131h10m to go
config:

NAME STATE READ WRITE CKSUM
amd64rio ONLINE 0 0 0
mirror ONLINE 0 0 0
ad6p3 ONLINE 0 0 0
ad10p3 ONLINE 0 0 0

errors: No known data errors

Состояние разметки устройств


Подготовительные операции для перехода на новую схему:

% echo 'geom_label_load="YES"' >> /boot/loader.conf
% shutdown -r now
% glabel list
Geom name: ad6p1
Providers:
1. Name: gpt/rio_boot
Mediasize: 131072 (128K)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 256
length: 131072
index: 0
Consumers:
1. Name: ad6p1
Mediasize: 131072 (128K)
Sectorsize: 512
Mode: r0w0e0

Geom name: ad6p1
Providers:
1. Name: gptid/6e56389f-81a6-11de-8aa6-02508d92a2eb
Mediasize: 131072 (128K)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 256
length: 131072
index: 0
Consumers:
1. Name: ad6p1
Mediasize: 131072 (128K)
Sectorsize: 512
Mode: r0w0e0

Geom name: ad6p2
Providers:
1. Name: gpt/rio_swap
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 4194304
length: 2147483648
index: 0
Consumers:
1. Name: ad6p2
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Mode: r0w0e0

Geom name: ad6p2
Providers:
1. Name: gptid/e0fa02b3-81a6-11de-8aa6-02508d92a2eb
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 4194304
length: 2147483648
index: 0
Consumers:
1. Name: ad6p2
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Mode: r0w0e0

Geom name: ad6p3
Providers:
1. Name: gpt/rio_zfs
Mediasize: 317921280000 (296G)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 620940000
length: 317921280000
index: 0
Consumers:
1. Name: ad6p3
Mediasize: 317921280000 (296G)
Sectorsize: 512
Mode: r0w0e0

Geom name: ad6p3
Providers:
1. Name: gptid/1f26a2d6-81a7-11de-8aa6-02508d92a2eb
Mediasize: 317921280000 (296G)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 620940000
length: 317921280000
index: 0
Consumers:
1. Name: ad6p3
Mediasize: 317921280000 (296G)
Sectorsize: 512
Mode: r0w0e0

Geom name: ad10p1
Providers:
1. Name: gptid/a01d172c-81a6-11de-8aa6-02508d92a2eb
Mediasize: 131072 (128K)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 256
length: 131072
index: 0
Consumers:
1. Name: ad10p1
Mediasize: 131072 (128K)
Sectorsize: 512
Mode: r0w0e0

Geom name: ad10p2
Providers:
1. Name: gptid/e2aef92e-81a6-11de-8aa6-02508d92a2eb
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 4194304
length: 2147483648
index: 0
Consumers:
1. Name: ad10p2
Mediasize: 2147483648 (2.0G)
Sectorsize: 512
Mode: r0w0e0

Geom name: ad10p3
Providers:
1. Name: gptid/20db981e-81a7-11de-8aa6-02508d92a2eb
Mediasize: 317921280000 (296G)
Sectorsize: 512
Mode: r0w0e0
secoffset: 0
offset: 0
seclength: 620940000
length: 317921280000
index: 0
Consumers:
1. Name: ad10p3
Mediasize: 317921280000 (296G)
Sectorsize: 512
Mode: r0w0e0

Процесс отвязки носителей от "устройств"


1. Вывод из зеркала одного носителя и его полная очистка "для чистоты эксперимента"

% zpool detach amd64rio ad10p3
% zpool status
pool: amd64rio
state: ONLINE
scrub: scrub in progress for 0h0m, 0,00% done, 69h45m to go
config:

NAME STATE READ WRITE CKSUM
amd64rio ONLINE 0 0 0
ad6p3 ONLINE 0 0 0

errors: No known data errors
% dd if=/dev/zero of=/dev/ad10p3 bs=100m
dd: /dev/ad10p3: short write on character device
dd: /dev/ad10p3: end of device
3032+0 records in
3031+1 records out
317921280000 bytes transferred in 5836.782166 secs (54468587 bytes/sec)

2. Задание метки

% gpart modify -i 3 -l rio_zfs2 ad10
ad10p3 modified
% shutdown -r now

3. Внесение носителя в зеркало

% zpool attach amd64rio ad6p3 gpt/rio_zfs2
% zpool status
pool: amd64rio
state: ONLINE
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scrub: resilver in progress for 0h3m, 17,22% done, 0h17m to go
config:

NAME STATE READ WRITE CKSUM
amd64rio ONLINE 0 0 0
mirror ONLINE 0 0 0
ad6p3 ONLINE 0 0 0 7,80M resilvered
gpt/rio_zfs2 ONLINE 0 0 0 9,08G resilvered

errors: No known data errors

4. После окончания репликации проделываем аналогичную операцию с другим носителем

% zpool detach amd64rio ad6p3
% zpool status
pool: amd64rio
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
amd64rio ONLINE 0 0 0
gpt/rio_zfs2 ONLINE 0 0 0

errors: No known data errors
% gpart modify -i 3 -l rio_zfs1 ad6
ad6p3 modified
% dd if=/dev/zero of=/dev/ad6p3 bs=100m
dd: /dev/ad6p3: short write on character device
dd: /dev/ad6p3: end of device
3032+0 records in
3031+1 records out
317921280000 bytes transferred in 5950.955982 secs (53423564 bytes/sec)
% shutdown -r now
% zpool attach amd64rio gpt/rio_zfs2 gpt/rio_zfs1
% zpool status
pool: amd64rio
state: ONLINE
scrub: resilver completed after 0h21m with 0 errors on Wed Aug 12 17:44:06 2009
config:

NAME STATE READ WRITE CKSUM
amd64rio ONLINE 0 0 0
mirror ONLINE 0 0 0
gpt/rio_zfs2 ONLINE 0 0 0 123M resilvered
gpt/rio_zfs1 ONLINE 0 0 0 52,7G resilvered

errors: No known data errors


Это всё.