Начиная с LTO-5, стандарт ленты предусматривает её партиционирование, то есть разделение на части, в одной из которых, грубо говоря, хранятся адреса файлов на ленте, а во второй — собственно содержимое файлов.
Эта вещь позволила создание на ленте файловой системы (LTFS — Linear Tape File System), которая в линуксе монтируется через FUSE. Естественно, природа носителя накладывает свои ограничения, например, удаление файла не приводит к увеличению свободного места. Зато, как ни удивительно, поддерживаются sparse files, если это кому-то нужно на архивных носителях.
Конечно, доступ к ленте в режиме файловой системы интересен, потому что даже LTO-5 — это уже 1.6 терабайта, а такое количество данных не всегда единовременно доступно к бэкапу, а многосессионная лента с tar-ами — это не так чтобы очень удобно.
Короче, всё было за внедрение: наличествует HP half-height internal LTO-5 драйв и некоторое количество LTO-5 картриджей. Увага: несмотря на то, что LTO5-привод способен писать LTO4-ленты, создавать LTFS на этих LTO4-лентах нельзя!
Путём чтения Википедии выяснилось, что для линукса как бы существует несколько реализаций от разных вендоров. Плюс нашёлся ещё относительно живой проект на Гитхабе, с которого и решил начать. Быстро выяснилось, что начал в какое-то неудачное время, потому что собираться на Debian Buster оно не очень хотело из-за поломанного в этом релизе дебиана pkgdata и отсутствующего icu-config в ICU. Собрал на stretch, перенёс на целевую машинку с buster-ом и приводом (тупо скопировал руками три недостающих библиотеки) — запустилось, но ругнулось на неподдерживаемый привод. Пошёл читать issues — да, действительно, оказалось, что этот проект поддерживает только привода IBM.
Гугль упрямо продолжал говорить, что HP-шные устройства поддерживаются под линуксом. Увы, но сайт HP не позволяет скачать линуксовую софтину для LTFS «просто так», требуя логина и пароля, которых у меня нет. Получить их я не пытался, может быть, это просто, не знаю. Поэтому почитал ещё интернетов и попробовал поставить Quantum LTFS. Сразу скажу, до компиляции там даже не дошло, потому что стало очевидно, что у этого кода очень много общего с гитхабовским проектом, но в него добавлена пара квантумовских приводов. Попытки прописать в код идентификатор моего привода я оставил на чёрный день, а пока что поиски привели меня на сайт Оракла. Скачал 64-битный RPM версии 1.2.7 для Oracle server 7.2, сконвертировал его alien'ом, установил, попробовал запустить, нашёл в репозиториях седьмой центоси три библиотеки из ICU нужной (50-й) версии, опытным путём подредактировал ltfs.conf — ура! mkltfs покрутил ленту и сказал, что OK, а основной бинарник (он у Оракла не ltfs, а что-то там про singledrive) без проблем смонтировал ленту в каталог. А, нет, одна мелкая проблема была: им нельзя передать в качестве устройства /dev/st0 или /dev/nst0, потому что они не могут смапить его имя в /dev/sgX из-за отсуствия в дебиановском ядре поддержки SCSI_PROCFS и /proc/scsi как такового. Зато они замечательно принимают прямо generic device name, которое можно получить из вывода lsscsi -g.
Результат — примерно 55 мегабайт в секунду на запись через scp. Может, получалось бы и ещё быстрее, но процессор на машинке не ахти.
Эта вещь позволила создание на ленте файловой системы (LTFS — Linear Tape File System), которая в линуксе монтируется через FUSE. Естественно, природа носителя накладывает свои ограничения, например, удаление файла не приводит к увеличению свободного места. Зато, как ни удивительно, поддерживаются sparse files, если это кому-то нужно на архивных носителях.
Конечно, доступ к ленте в режиме файловой системы интересен, потому что даже LTO-5 — это уже 1.6 терабайта, а такое количество данных не всегда единовременно доступно к бэкапу, а многосессионная лента с tar-ами — это не так чтобы очень удобно.
Короче, всё было за внедрение: наличествует HP half-height internal LTO-5 драйв и некоторое количество LTO-5 картриджей. Увага: несмотря на то, что LTO5-привод способен писать LTO4-ленты, создавать LTFS на этих LTO4-лентах нельзя!
Путём чтения Википедии выяснилось, что для линукса как бы существует несколько реализаций от разных вендоров. Плюс нашёлся ещё относительно живой проект на Гитхабе, с которого и решил начать. Быстро выяснилось, что начал в какое-то неудачное время, потому что собираться на Debian Buster оно не очень хотело из-за поломанного в этом релизе дебиана pkgdata и отсутствующего icu-config в ICU. Собрал на stretch, перенёс на целевую машинку с buster-ом и приводом (тупо скопировал руками три недостающих библиотеки) — запустилось, но ругнулось на неподдерживаемый привод. Пошёл читать issues — да, действительно, оказалось, что этот проект поддерживает только привода IBM.
Гугль упрямо продолжал говорить, что HP-шные устройства поддерживаются под линуксом. Увы, но сайт HP не позволяет скачать линуксовую софтину для LTFS «просто так», требуя логина и пароля, которых у меня нет. Получить их я не пытался, может быть, это просто, не знаю. Поэтому почитал ещё интернетов и попробовал поставить Quantum LTFS. Сразу скажу, до компиляции там даже не дошло, потому что стало очевидно, что у этого кода очень много общего с гитхабовским проектом, но в него добавлена пара квантумовских приводов. Попытки прописать в код идентификатор моего привода я оставил на чёрный день, а пока что поиски привели меня на сайт Оракла. Скачал 64-битный RPM версии 1.2.7 для Oracle server 7.2, сконвертировал его alien'ом, установил, попробовал запустить, нашёл в репозиториях седьмой центоси три библиотеки из ICU нужной (50-й) версии, опытным путём подредактировал ltfs.conf — ура! mkltfs покрутил ленту и сказал, что OK, а основной бинарник (он у Оракла не ltfs, а что-то там про singledrive) без проблем смонтировал ленту в каталог. А, нет, одна мелкая проблема была: им нельзя передать в качестве устройства /dev/st0 или /dev/nst0, потому что они не могут смапить его имя в /dev/sgX из-за отсуствия в дебиановском ядре поддержки SCSI_PROCFS и /proc/scsi как такового. Зато они замечательно принимают прямо generic device name, которое можно получить из вывода lsscsi -g.
Результат — примерно 55 мегабайт в секунду на запись через scp. Может, получалось бы и ещё быстрее, но процессор на машинке не ахти.