API Для работы с ленточными библиотеками

Если что, ПО из которого хочется общаться с устройством написано на яве, но есть возможность дергать сишные библиотеки, да и просто исполнять комманды операционки.

Если я правильно понял, то man dump, man restore, man tar, man dd — всё это изначально работало и разрабатывалось именно для ленточных устройств. (Кроме последнего — оно ещё древнее, из до-unix-эры.)

Да, что старые ленты работали с помощью обычного tar и dd я в курсе. А вот как с этим у современных устройств? Они так-же все это поддерживают? И что с работой по сети? Эта штука умеет только физически подключаться к серверу приложений, или с ней можно работать по сети?

то есть в гугл вы не ходили?

в ОС должен быть драйвер, который создает файл устройства, и с ним уже можно работать через обычный read()/write()/ioctl() (для перемотки и смены кассеты например). вообще удобнее через какой-нибудь нормальный софт для бекапов, скажем, Netbackup.

а что именно ты хочешь сделать?

мы в свое время использовали amanda как высокоуровневое API для того чтобы достать/положить файлы на ленты, было очень удобно, не забывайте только учитывать количество перемоток покассетно, оно очень небольшое (пара сотен) и этот ресурс стоит беречь :)

Интересует возможность программного доступа к данным с ленточки

man mt

А само устройство доступно как символьный scsi девайс.

Ага, примерно понятно, спасибо.

а что именно ты хочешь сделать?

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

Ага, спасибо. Но о перемотках заботиться смысла нет, громадное количество данных будет складироваться, но обрабатывать из них надо будет дай бог 1%, как я писал в комментарии выше.

Ок, спасибо. Остается последняя проблема, софт крутится на виртуалке и надо будет либо пробрасывать в виртуалку как-то это устройство, либо рыть ibm-овские мануалы по поводу сетевого доступа.

Библиотека - композитное устройство. Состоит из робота и собственно магнитофонов. Рулится всё исключителдьно SCSI командами.

А вот и сам http://www-01.ibm.com/support/docview.wss?uid=ssg1S7003245&aid=1

Я работал с TS3310. Media-changer обычно виден как /dev/smc0, драйвы - как /dev/rmtX. Помимо mt у IBM есть свои утилитки (itdt, tapeutil) для работы с ними.
Еще у библиотеки есть веб-интерфейс и даже какой-то CLI на джаве (я его не юзал). Внутри там Linux на PPC =)

веб-интерфейс и даже какой-то CLI

Нужен для отсылки алярмов :) в системы мониторинга

Нужен для отсылки алярмов :) в системы мониторинга

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

О, спасибо за ссылку, надо изучить

и еще TS3310 Command Line Interface

Ага, ясно, спасибо. А она умеет все-таки работать по сети, или только как scsi устройство? Просто первый способ предпочтительней, поскольку наше приложение крутится в виртуальной среде. Т.е. понятно, что если по другому никак, то можно попробовать устройства в виртуалку прокинуть, либо подключить к отдельному серверу и написать демон, который будет транслировать комманды. Но если оно из коробки поддерживает какой-то апи, то это сильно удобнее.

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

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

Но все равно на ленту можно писать только как на блочное устройство

Как на символьное устройство. Блочное устройство предполагает произвольный доступ.

Как на символьное устройство.

Да, ты прав.

Блочное устройство предполагает произвольный доступ.

Зависит от самого устройства и ОС. В *nix (Solaris, AIX) у дисков есть символьные устройства с произвольным доступом.
Символьное устройство не предполагает буферизации.

Присоединяюсь к уже данному здесь выше совету заюзать какое-нибудь высокоуровневое API (amanda? bacula?), чтобы самому не возиться с ленточками.

Символьное устройство не предполагает буферизации

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