amarao (amarao_san) wrote,
amarao
amarao_san

Categories:

патчим #anime под FreeBSD

Часть третья. Предыдущие части: http://amarao-san.livejournal.com/tag/animelife

Итак, речь сейчас пойдёт о месте хранения комплитов.

Для начала, небольшой экскурс в эпоху раннего HDTV. Ещё в 60ые, первые протоотаку хранили протоаниме на бобинах с плёнкой. Потом плёнку сменили кассеты, и появились квартиры, наполненные VHS чуть более, чем наполовину. К этому времени аниме было ещё относительно мало. Во-первых, многие сериалы были в уникальных коллекциях, во-вторых, до середины 90ых аниме было на 15 лет меньше, чем его сейчас.

Потом пришла цифровая эпоха. Пришла она робко и грустно, это были rm (с битрейтом от 150 до 300кбпс; да-да, фанаты MP3, видео было меньше, чем mp3 320кбпс). Были незабвенные viv'ы, плеер которых показывал только 256 цветов (шок! viv'ы были полноцветными, а смешные точечки - это глюк плеера), и который не умел перемотку. Главной проблемой rm и viv'ов, помимо битрейта и разрешения, были 15 фпс. Ужасно...

Разумеется, довольно приличная часть аниме шла в 320х200, оставшееся - в ещё меньших разрешениях. Появление на свет разрешений уровня 512х384 было как небесная благодать, а уж 640х480 в те времена называлось HQ и игралось не на всех компьютерах без лагов.

Возникла необходимость всё это хранить. По состоянию на 2000ый год, только-только вышли жёсткие диски в 6-8Гб (потом был приличный временной лаг до момента появления 10Гб моделей). Размер сериала в VIV составлял примерно 1.1Гб на 26 серий, в RM около 800Мб (если я не путаю). Были ещё роскошные рипы в MPG 320x240 с полными FPS, но занимали они многомногомного места. Иногда по 3Гб на сериал.

Как понятно, хранить аниме на жёстких дисках было невозможно. И его хранили на CD. Как легко понять, сотня гигабайт выливалась в пачку из примерно 130-140 дисков.

Главной же проблемой была не стоимость квадратного метра жилья (тогда она была ниже, чем соответствующий объём болванок), а нарезка сериала по дискам. Во-первых, даже rm'ы, большей частью на CD не влазили целиком. Значит, их нужно было хранить по кусочкам. Если для мелких файлов это было ещё вполне нормально (сериал занимал полтора диска, т.е. резался попалам), то к моменту появления 250Мб монстров, ситуация сводилась к тому, что на диск влазило 2 серии. Представьте себе 96-серийный сериал (напр., Maison Ikkouku) в таком формате. Всего 48 дисков. Банка на 50 болванок - под один сериал.

Ещё большей подлостью была проблема "набивки" - место жалко, и если у нас серия 250Мб, то мы пишем на болванку две серии, и у нас остаётся 150-200Мб места. Что делать?? Правильно, писать сериалы в параллель. Т.е. 1-2 толстых серий, 1-2 маленьких серий.

А размер серий рос! Росло разрешение, и 640х360 начало становиться мейнстримом.

Путаница при этом была страшная.

Цитирую из античного, содержимое некоторых дисков. Одна строка - один диск.
Slayers TV (mpeg4) [3-4], record of lodoss wars [13]
Escaflowne [25], divx (720x480),dub,Gayver (dub)[1-2],Project ARMS[1]
Card Captor Sakura [1-7], Onegai Teacher [12]

Жуть, правда? А ведь это ещё не затронуло вопрос "как хранить фильмы с размером больше диска". Тут уж был полный кошмар: SVCD (который позволял писать аж 800Мб на обычную болванку), запись видео в многотомных архивах, разрезание видео на кусочки с "оверлапом" по времени и т.д. и т.п.

Потом появились DVD. Оставляя в стороне эпический пшик под названием "Битва плюса и минуса", стало чуть легче. Потеря 100-200Мб уже не была таким расточительством, и сериалы снова начали влазить на 1-2-3 диска. Иногда целиком.

Но это всё ещё не решало проблемы с ситуацией, что сериал надо пихать на несколько дисков.

И выглядело это так:

Asagiri no Miko [20-26], Gantz [1-11], Paranoia Agent [1-13]
Sailor Moon S1 [1-12]
Sailor Moon S1 [13-24]

жуть. Особая жуть была в необходимости либо вести список руками, либо использовать особые индексаторы дисков.

И, наконец, появились дешёвые 250-320Гб модели винчестеров. С ценой около 8р за гигабайт. Что было несколько дороже цены на болванках, но было безмерно удобнее.

Именно в этот момент и родился HDDLib (мечты о нём появились сильно раньше)

(конец исторического экскурса)

В кратце, плюсы HDDLib:

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

2) Носители достаточно большие, чтобы раз и на всегда отказаться от разрезания сериалов на кусочки. Даже если это 1023-серийный ванпис объёмом в 380Гб)

3) Хранение винтов на полочках не приводит к их износу, большу часть времени они лежат без движения.

Есть и минусы:

1) Уронил жёсткий диск - прощай 500-1000Гб аниме.
2) rm -r страшная штука

Итак, как он устроен? Очень просто: винчестер (SATA, благо все новые системы с SATA2 умеют hotplug), на нём каталоги с аниме.

Структура названия описана тут: http://desunote.ru/desu/Anime:HDDLib

Вопрос с индексацией. Всё решается очень просто: простейший скрипт в корне каждого диска, файл с меткой - и всё готово. Скрипт создаёт копию файловой системы в каталоге /pub/HDDLib/vol_name с файлами нулевого размера. По ним очень удобно искать с помощью find.

Вот скрипт:


#!/usr/bin/python
#Settings

HDDLib_path="/pub/HDDLib/"
skip_dirs=("_backup", "System Volume Information")


import os, sys


current_path=os.getcwd()

label=open(os.path.join (current_path,"label")).read()
mirror_path=os.path.join (HDDLib_path,label)

def strsub(long_name, part_name):
	if long_name[0:len(part_name)] == part_name:
		return long_name[len(part_name)+1:]
	else:
		return long_name

os.system("rm -rf "+mirror_path)
for a in os.walk(current_path):
	walk_dir=strsub(a[0],current_path)
	if walk_dir in skip_dirs:
		continue
	mirror_dir=os.path.join(mirror_path,walk_dir)
	try:
		os.makedirs(mirror_dir)
	except:
		print "error creaing: ", mirror_dir
	for f in a[2]:
		ff=os.path.join(mirror_dir,f)
		try:
			file(ff,"w")
		except:
			print "error creating: ", f




Как этим пользоваться я описывал уже раньше.
Tags: anime, animelife, история аниме
Subscribe

  • systemd-networkd, netlink и arp флуд

    Нереально странный баг пофикшен с помощью eBPF затычки. Для меня большой неожиданностью является реакция на него.…

  • Rust soundness

    Каждый раз, когда я сталкиваюсь с маленькими "но" в Rust'е, это ощущение тщательной продуманности. Например, простейшие fold-функции для итераторов:…

  • still_ntp

    В ходе локального мозгового штурма у меня родилась суперидея. Надо написать ntp сервер, который может отдавать указанную дату. Т.е. сказали при…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 14 comments

  • systemd-networkd, netlink и arp флуд

    Нереально странный баг пофикшен с помощью eBPF затычки. Для меня большой неожиданностью является реакция на него.…

  • Rust soundness

    Каждый раз, когда я сталкиваюсь с маленькими "но" в Rust'е, это ощущение тщательной продуманности. Например, простейшие fold-функции для итераторов:…

  • still_ntp

    В ходе локального мозгового штурма у меня родилась суперидея. Надо написать ntp сервер, который может отдавать указанную дату. Т.е. сказали при…