LINUX.ORG.RU

Нужны мысли по организации хранения файлов.

 , , , ,


3

4

Задача — утягивать файлы по url (видео, картинки) и складировать в хранилище. Так, чтобы впоследствии по url можно бы было получить сразу локальный файл. Без БД.

Файлов много, десятки, сотни тысяч. Количество год от года растёт.

Первый, много лет назад вариант был тупым — берём md5(url), разбиваем на две вложенности по два символа и сохраняем файл — storage/dd/75/dd753e96f09cf8afedc9882da55977a2.jpg

Попутно можно там же положить одноимённый .txt со ссылкой на исходный файл для обратного поиска.

Вариант всем хорош для небольших объёмов. На больших, да ещё под ext4, которая по мере старения на таких структурах начинает чудовищно тормозить, получился ад при любых работах по бэкапу/настройкам. rsync, занимающий десятки минут — это жесть. Если для аналогичного подхода с аттачами, имеющими дату вопрос решается просто — Мысли вслух. Предостережение от наступления на грабли. , то для произвольных ссылок так уже не поступить.

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

Вторая версия была устроена чуть иначе. Файлы кладутся в каталоги, напоминающие исходные домены и пути. Например, storage/ru/li/linux.org.ru/tango/img/opensource-logo.png

Как ни странно, такая структура даже чуть легче при копировании, гораздо удобнее при анализе. Но всё равно очень избыточна и тяжела. Кроме того, возникают проблемы с URL, содержащими сложные для имён файлов символы — get-запросы и т.п.

Сейчас стоит задача сделать что-то подобное с нуля и можно подумать над более оптимальным решением. В голову всё равно ничего более толкового не приходит. Тем более, что вопрос «человекочитаемости» хранящихся данных в новой задаче становится даже более высоким, чем ранее.

Есть мысли, куда копать?

Update из темы:

— Задача: «архивирование Интернета». Через 5..10..15 лет остаётся очень мало доступных картинок, видео, аудио, на которые ссылаются на форумах. Хочется это дело эффективно кешировать, да ещё и раздавать потом через btsync желающим, тем более, что форумы планируется переводить на распределённый формат — Распределёные форумы/блоги. Продолжаем разговор. Нужен совет.

— Подразумевается использование в рамках p2p-системы на базе btsync или будущих аналогов. Т.е. никаких файлоспецифичных вещей, метаданных, спецсимволов и т.п. Должно работать хоть на vfat.

— Желательно, чтобы система могла уметь дробиться на отдельные архивы/репозитории.

— Вопрос индексирования мало актуален, т.к. данная система подразумевается бэкендом. Перед фронтедом может стоять кеширующая полноценная БД.

— Желателен человекочитаемый формат, чтобы можно было разгребать систему вручную.

— Участники обмена должны иметь возможность передавать данные в т.ч. из-за «серых NAT», потому и ориентируюсь на btsync и аналоги.

Так как-то.

★★★★★

Последнее исправление: KRoN73 (всего исправлений: 2)

т. е. ты хочешь сказать что это все не работает?

а как-же остальные известные сервисы умудряются?

anonymous
()

elliptics, если не хочешь оверхед ФС. Вместо rsync будет просто второй инстанс elliptics.

Кроме того, возникают проблемы с URL, содержащими сложные для имён файлов символы — get-запросы и т.п.

Это какие сложности? ext умеет All bytes except NUL ('\0') and '/' and the special file names "." and ".." . Никогда таких URL не видел в природе

disarmer ★★★
()

IMHO все упирается в единое хранилище.

Раз объем данных стал слишком большой, значит его нужно разбивать на части. Части хранить отдельно. Соответственно индексную информацию тоже можно/нужно разбвать на части.

Так мы пришли к идее распределенного хранилища.

Да, время поиска увеличится, но это расплата за существенное увеличение объема хранимых данных.

удобство и масштабируемость взаимоисключающие вещи. IMHO - Человекочитаемость - это удобных поиск.

Бекап будет не один здоровый, а несколько частей. И процесс выполнения бекапа будет распараллелен.

С производительностью тоже будет лучше - запросы в разные секции могут выполняться одновременно.

Выход их строя одной части не убъет всю систему.

Только вот сложность самой системы возростает :(

Из существующих близких решений - squid с multicast peers

vel ★★★★★
()

Файлов много, десятки, сотни тысяч

Немного же? Может ФС как-то потюнить? Попробовать другую?

Если файлы только добавляются, не изменяются или удаляются (хотя можно и это предусмотреть) - сваливай файлы в здоровые блобы, индекс с метаданными держи отдельно. Хоть в sqlite, на таких объемах не должно тормозить

anonymous
()

А нафига там вообще rsync? Файло же, как я понял, неизменяемое. Или изменяемое?

thesis ★★★★★
()

Без БД.
Файлов много, десятки, сотни тысяч. Количество год от года растёт.

Эмммм... И метаданные без БД? Тогда поиск боюсь будет унылый-унылый...

Pinkbyte ★★★★★
()
Ответ на: комментарий от Y

какая разница? Всяко лучше велосипеда, особенно если теперь нужно из Питера в Москву ездить, и велосипед это оверкилл.

Например MarioDB.

emulek
()

Без БД.

извращенец? Твоя задача как раз для СУБД.

И да, файловая система — тоже СУБД. Только не для твоего юзкейса, что ты уже заметил.

emulek
()

под ext4, которая по мере старения на таких структурах начинает чудовищно тормозить

открой для себя ФС умеющие cow и сжатие

anonymous
()
Ответ на: комментарий от disarmer

elliptics

Это должна быть обычная (и любая, хоть VFAT) ФС. Стоит задача раздачи данных через BTSync.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от vel

Раз объем данных стал слишком большой, значит его нужно разбивать на части

Да, забыл в топикстарте указать, что это тоже желательно.

Я сейчас склоняюсь к такому варианту. Есть отдельный «архив связей». Где в упомянутом формате упрощённо хранятся *.txt, соответствующие ссылкам. Скажем, storage-index/ru/li/$(md5sum(tango/img/opensource-logo.png)). Внутри файла уже указан архив (например, разбивка по годам) и путь.

.txt россыпью вместо, скажем, одного .json (или .sqlite) — чтобы не было конфликтов встречной модификации из разных источников.

KRoN73 ★★★★★
() автор топика

nginx + document root (ну или по вкусу) на эту фс
find . * > filelist.txt
И дергай что хочешь, откуда хочешь и чем хочешь.

handbrake ★★★
()
Ответ на: комментарий от disarmer

ext умеет All bytes except NUL

Но не умеет vfat или URL. Ещё одна задача — раздавать эти файлы от себя по http, как простые файлы.

Сорри, забыл основную задачу указать — «архивирование Интернета». Через 5..10..15 лет остаётся очень мало доступных картинок, видео, аудио, на которые ссылаются на форумах. Хочется это дело эффективно кешировать, да ещё и раздавать потом через btsync желающим, тем более, что форумы планируется переводить на распределённый формат — Распределёные форумы/блоги. Продолжаем разговор. Нужен совет.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от thesis

А нафига там вообще rsync?

Просто для наглядного примера. Вообще, подразумевается периодическое сканирование через тот же btsync. Ну и сам rsync для синхронизации реплик через lsyncd.

Или изменяемое?

Добавляются новые файлы. При чём в варианте с разбивкой по md5 добавляются в уже имеющиеся каталоги в произвольном порядке.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Pinkbyte

И метаданные без БД? Тогда поиск боюсь будет унылый-унылый...

Это способ базового хранения. БД используется как индексирующий кеш на конкретном хосте. При чём в общем случае, понятно, произвольная БД. Либо её отсутствие при ручной работе :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

Немного же? Может ФС как-то потюнить? Попробовать другую?

Структура должна быть эффективной на любой ФС. А так, где можно, я итак на reiserfs возвращаюсь, она намного эффективнее на таких задачах, оказывается :)

сваливай файлы в здоровые блобы

Там сейчас десятки гигов за год. И запросы растут.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

а как-же остальные известные сервисы умудряются?

Х.з. Но у них нет тех задач, что я сейчас ставлю :) Если бы тупо всё только под себя рассчитывать, то проблем бы не было. БД с репликацией, rsync/lsyncd и/или gluster — и голова бы не болела.

Но нужна система, которая позволит обеспечить доступ к данным хоть из под домашней винды юзера средней квалификации. И которую можно дробить на компоненты, чтобы заинтересованному только в части данных не тянуть сотни гигабайт мусора.

...

В какой-то степени это можно считать одним из механизмов «нового ФИДО» :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от emulek

Всяко лучше велосипеда
Например MarioDB

Лол, что? Как ты думаешь, почему никакой high-load так не делает? Хранит в своей БД имя/адрес файла, а читает его с диска?

Потому что ФС является СУБД, предназначенной для хранения бинарных файлов. MariaDB решает немного другие задачи и на огромных хранилищах бинарных файлов эпично соснёт.

Без БД.

Твоя задача как раз для СУБД.

Нормальная у него задача. Он же не абсолютно от бд отказывается. А просто не хочет обращаться к БД для отдачи файла по URL (о поиске ведь речи нет) и при этом ищет наиболее удобный, производительный и человекопонятный способ организации их на диске. Искать такой способ и так и так надо, а первую задачу решить вполне себе реально заодно. Так почему нет?

Y ★★
()
Последнее исправление: Y (всего исправлений: 1)

Много потому-что в основном мелочевка. Это как на «фатную» флэшку или по фтп, ssh, scp, webdav копировать много мелких файлов - «моргни и ты не забудешь это, закусывая французскими булочками для фитнеса». Обычно, если «затарить» или просто заархивировать, копируется очень быстро. Это снизит на порядки кол-во мелких файлов.

В некоторых случаях помогает тюнинг фс с размерами блоков.

Может по аналогии хранить блоками?

Вообще попахивает партициями БД, но тут проблема в том, что по возможности надо распределять по времени...

anonymous
()
Ответ на: комментарий от anonymous

представь что находишься в роли гугла, флицкера, инстаграммы, на фазе роста...

Если бы у меня была деловая хватка Брина или Цукерберга, то история Интернета развивалась бы немного иначе :)

KRoN73 ★★★★★
() автор топика

IMHO, база данных тут самое то, но не обязательно она должна быть реляционной. MongoDB должна неплохо справиться.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

MongoDB должна неплохо справиться

Плохо. Не получится простой прозрачной синхронизации данных всех участников с локалхостами. В т.ч. за серыми NAT'ами :)

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

KRoN73 ★★★★★
() автор топика

имхо тут нужно уже отдельную железку под файловое хранилище

идея такая чтобы индекс файловой системы целиком висел в памяти

опятьже тогда бекап сведется к копированию всей фс (без пустого места) а не файлов

Deleted
()
Ответ на: комментарий от KRoN73

Плохо. Не получится простой прозрачной синхронизации данных всех участников с локалхостами.

Документ может состоять только лишь из URI как ключа и собственно значения. Это мало чем отличается но простого хранения в виде файлов на диске, но не имеет ограничения по длине имени и используемым символам.

i-rinat ★★★★★
()
Ответ на: комментарий от Deleted

Дописал update к топикстарту :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от i-rinat

Это мало чем отличается но простого хранения в виде файлов на диске, но не имеет ограничения по длине имени и используемым символам.

Это сразу на порядок-другой сократит численность активных участников сети. А их итак вряд ли будет много. Боюсь, что с вариантом MongoDB вообще не получится стартовать :) А вот с file/btsync можно будет привлечь ограниченное число желающих попробовать точно.

По используемым символам — при отдаче файлов через web придётся всё равно этот вопрос решать. urlencode ужасен :)

KRoN73 ★★★★★
() автор топика

Желательно, чтобы система могла уметь дробиться на отдельные архивы/репозитории.

хранить отдельно от документа список его список

anonymous
()
Ответ на: комментарий от KRoN73

Это сразу на порядок-другой сократит численность активных участников сети

Да, с embedded у MongoDB вроде всё плохо, но можно же взять что-то типа kyoto cabinet.

Я считаю, что стоит делать приложение, которое будет заниматься и синхронизацией, и управлением хранилищем. Для отдачи контента на время работы приложения можно поднимать прокси сервер, который будет отдавать контент из хранилища, если он найден и лезть в интернет, если нет. Получится прозрачная такая работа. Запустил приложение, запустил браузер, сёрфишь.

i-rinat ★★★★★
()
Ответ на: комментарий от i-rinat

Я считаю, что стоит делать приложение

Это идеальный вариант. Задача-максимум у меня сделать распределённую защищённую от блокировок и потерь от сбоев систему форумы/блоги.

Фишка в том, что все попытки сделать подобное, начинались от системы. У которой нет пользователей. Соответственно, замкнутый круг — нет пользователей, мало материалов, мало интересующихся новых пользователей. Потом потеря интереса разработчиков и забвение.

Я пытаюсь танцевать, наоборот, от пользователей. Есть форум с 14-летней историей, десятком гигабайт текстов, сотней гигабайт аттачей и т.п. Есть десятки тысяч более-менее регулярных посетителей и миллионы посетителей случайных. Плюс возможность присоединить к этому ещё пару форумов поменьше. Соответственно, первая задача — попробовать объединить это всё в более-менее простую структуру, с которой может работать каждый желающий и через которую смогут синхронизироваться разнородные решения. В начале — просто как бэкенд для хранения данных. Которые можно будет просто скачать через p2p и/или git. Желающих иметь архивы форумов и сейчас не мало.

Следующий этап — перевод нынешних форумных движков фактически просто в web-шлюз к такой системе. А тут сразу наклёвывается и третий этап, про который ты говоришь — организация приложения для удобного локального просмотра базы форумов, в офлайне. С возможностью ответить потом пакетом через доверенный гейт (если конкретная нода/пир произвольного участника прямо писать в сеть не допускается). В пределе система может получиться эффективно работающей вообще без всякого центрального сервера. Web потребуется только для доступа из обычного Интернета пользователям, которым будет лениво ставить приложение или качать сотни гигов архивов. Получится защищённая от блокировок и запретов информационная сеть.

Но это всё дальние этапы, где будет много сложностей (в первую очередь на данном этапе — вопрос доверия и репутации пользователей, вопросы идентификации материалов разных источников и т.п.). Пока решаю задачи хранения и форматов. Заодно так, чтобы они легко обеспечивали и нынешние потребности форумов — те же внешние картинки у меня давно тянутся для сохранения на сервере. Но в неоптимальном, описанном в топикстарте формате. Теперь хочу хранить и короткие видео. Как всякие facebook/mp4, так и youtube, который в последнее время очень активно удаляет материалы на политические темы и т.п.

В общем, стараюсь пока решать мелкие задачи, понемногу приводящие систему к будущему распределённому виду и так, чтобы нынешний вид не ломался. ИМХО, это перспективнее, чем делать пустую систему с нуля и потом пытаться привлечь туда пользователей :)

KRoN73 ★★★★★
() автор топика

Для начала забудь про имена файлов и каталоги. Всё, что нужно для твоей системы - таблица соответствия inode (допустим, что inode уникален на всё хранилище или его том/репозиторий/архив/часть) <-> url.
Имена файлов и структуры каталогов хранения здесь вторичны и нужны лишь для удобства ручного копания в ФС или удовлетворения ограничений выбранной ФС. Вот во вторую очередь их в задачу и домешивай, раскладывая inode'ы, как тебе будет удобней в них копаться - по датам, источникам, назначениям, названиям или прочей лабуде.

blexey ★★★★★
()
Ответ на: комментарий от blexey

Всё, что нужно для твоей системы - таблица соответствия inode (допустим, что inode уникален на всё хранилище или его том/репозиторий/архив/часть) <-> url

Да, неизбежность этого механизма стала ясна: Нужны мысли по организации хранения файлов. (комментарий)

При чём с обратным преобразование, «inode» -> url проблем никаких. Кладём рядом с файлом файл с метаданными (.txt/.json/.md) и пишем там всё, что нужно, от url до списка использующих его ресурсов.

Вопрос в прямом преобразовании, url -> «inode». Так, чтобы оно [практически] не конфликтовало при встречных модификациях. Думаю попробовать вернуться к изначальной схеме. Тупо md5(url). Объёмы будут небольшие, хоть и сотни тысяч, в перспективе — миллионы записей, но по одной строке на файл. Если что, хоть в tmpfs в критичных по нагрузке местах хранить можно. Ну а локально всё равно будет кеш в БД.

Или, всё же, есть варианты получше, да я упускаю?

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

Пусть этим занимается код, возвращающий содержимое. Хранить таблицу можно как в простом файле, так и в базе данных, в которой уже есть быстрый поиск через индекс. Всё равно он окажется эффективней наколенных методов поиска URL.

Даже если запилить это в виде ВФС, или полноценной ФС, или слегка модифицированного архива, поиск URL в индексе неизбежен.

blexey ★★★★★
()
Ответ на: комментарий от KRoN73

Структура должна быть эффективной на любой ФС

Ну тогда простое соответствие url <-> файл-на-фс не получится

Придется несколько файлов держать в одном (скажем, размером до 2G). А индекс (+ метаданные, смещение в блобе и размер) держать отдельно

Можно перестраховаться и дублировать метаданные в блобах (на границах файлов, например), чтоб можно было восстановить индекс

К этому можно за неделю (ну, условно) написать ro-фс на fuse и ее отдавать в веб

anonymous
()
Ответ на: комментарий от Y

Лол, что? Как ты думаешь, почему никакой high-load так не делает? Хранит в своей БД имя/адрес файла, а читает его с диска?

лолка, кто сказал, что я предлагаю бинарные данные в БД хранить? Иди в школу лучше, может читать научишься.

Потому что ФС является СУБД

только если файлов не очень много. У ТСа их похоже слишком.

Он же не абсолютно от бд отказывается

там русскими буквами написано: «Без БД.» Если это «не совсем», то осталось выбрать СУБД, структуру таблиц, и тема решена.

А просто не хочет обращаться к БД для отдачи файла по URL (о поиске ведь речи нет)

это и есть поиск key→value.

Читай дальше, он хочет свою велосипедную СУБД сделать, с репликацией и бекапами.

Удачи тебе, ТС.

emulek
()
Ответ на: комментарий от i-rinat

MongoDB должна неплохо справиться.

согласен, если это простое key→value.

emulek
()

Без БД

ИМХО, никак.

Deleted
()

ты хочешь чтобы получилось что: каталогизатор нажитого непосильным трудом на тропинках интернета файла, или грубо говоря, wwwoffle, оффлайн прокси сервер с архивированием?

если первое, смотри в сторону tagstore

если второе, то «я джва года жду такое приложение», в конце концов, когда-нибудь плюну и допишу свою поделку на go (ковыряю неспешно свой велосипед на основе goproxy.

пока в ТЗ вырисовалось: «умный прокси сервер, с поддержкой версий документов и их жизненного цикла»:

0. goroutines, каналы и интерфейсы во все поля. кроссплатформность. повторная используемость кеша под разными ОС.
1. с онлайн/оффлайном
2. с тегами и категориями, категоризацией контента
3. записывает прозрачно вообще всё (возможно, вплоть до запросов) и проигрывает в офлайн 
4. CAM (content-addressable memory) для хранения файлов как «блобов» в git, адресуемых по хешу от содержимого
5. повторное использование одинаковых кусков, файлы как симлинки на блобы
6. импорт контента кеша прокси из MHT файлов, «нажитых непосильным трудом».
7. тегирование и категоризация: добавление своих пользовательских тегов и категорий. через расширение или bookmarklet для браузера. при этом эти теги и категории передаются нестандартными заголовками HTTP, обозначающими команды, и наружу не уходят. типа как Scrapbook или MyTetra на уровне прокси сервера.
8. команды: онлайн, офлайн, «прилепить» версию странички в кеше, сохранить новую версию, заменить текущую, заменять все текущие, ручные теги и категории, автоматические (на основе правил, в.т.ч. на контент) правила для тегов и категорий. 

«прилепленные» версии — «хранить вечно», не обновлять.

9. поковыряться в истории и кеше, поискать по содержимому или по тегам, объединить/разделить теги, перенести из категории в другую, отчёты за изменения в облаке тегов за день/неделю/месяц.

10. в идеале, какие-то процессы и автоматизация для перемещения.

пока неспешно пишется такая штука для себя, «just for fun» (ну, и ещё в свалке MHT на файловой системе разбираться неудобно, а в Scrapbook-е неудобно совсем).

может, какие-то соображения пригодятся.

anonymous
()

и складировать в хранилище. Так, чтобы впоследствии по url можно бы было получить сразу локальный файл. Без БД.

CAM-хранилище по образу git blobs или camlistore. в простейешем случае:

$D/cache
. $D/cache/blobs
. $D/cache/blobs/91/823781237671263 #sha1sum-of(content)
. $D/cache/site.net/index.html -> $D/cache/blobs/91/823781237671263
. $D/cache/site2.net/clon-of-index.html -> $D/cache/blobs/91/823781237671263  #same content

плюс. аналогичнм образом логировать запросы и ответы проксика (без учёта различия в user-agent, и т.п. «лишних» заголовков)

anonymous
()

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

попутно пишется индекс, как в git index:

123012903891239deaddcafe site1.net/index.html
123012903891239deaddcafe site2.net/tozhe-index.html

Вторая версия была устроена чуть иначе. Файлы кладутся в каталоги, напоминающие исходные домены и пути. Например, storage/ru/li/linux.org.ru/tango/img/opensource-logo.png

у меня было совмещённое, первое и второе. то есть, вторые файлы тоже есть, но это симлинки на $D/cache/blobs/123012903891239deaddcafe

симлинки обновляются синхронно, то есть если появляется новая версия , и старая не «прилеплена» — удаляется старая, если последняя, то блоб, если не последняя — то только ссылки.

ну или можно libgit взять и блобы на низком уровне ковырять. или вообще camlistore.

идея, чтобы прозрачно бекапилось сначала rsync-ом, а потом и btsync-om — в планах.

— Желателен человекочитаемый формат, чтобы можно было разгребать систему вручную.

простой текстовый, как в git index или git commit, git tree objects.

— Вопрос индексирования мало актуален, т.к. данная система подразумевается бэкендом. Перед фронтедом может стоять кеширующая полноценная БД.

с индексированием, морфологией и разными форматами если не число plain text (gzip или mht qp) — заморочки, да. БД в моей поделке если и нужна вообще, то только для метаданных. вообще идея, что набор метаданных может произвольно добавляться, расширяться.

anonymous
()

Кроме того, возникают проблемы с URL, содержащими сложные для имён файлов символы — get-запросы и т.п.

такие имена файлов в путях надо переделывать, конечно же. в винде с этим вообще печально, а мне нужна кроссплатформенность. переделывать наиболее простым, однозначным способом. в любом случае, URL не должен быть индексом (ключом), а только значением — одним из дополнительных, альтернативных логических путей. адрес блоба — хеш от его содержимого. остальные «логические» пути — это симлинки на блоб. ну почти как в gitfs.

anonymous
()
Ответ на: комментарий от Y

например, MUMPS-подобную GT.M. М-глобалы идеально подходят для ключ-значение.

или, если попроще: camlistore, например.

anonymous
()
Ответ на: комментарий от KRoN73

Но не умеет vfat или URL. Ещё одна задача — раздавать эти файлы от себя по http, как простые файлы.

camlistore put / camlistore get

anonymous
()
Ответ на: комментарий от KRoN73

В какой-то степени это можно считать одним из механизмов «нового ФИДО» :)

ещё глянь IPFS.io и Iris (их papers про устройство)

поверх этого элементано пишется такая простая вещь, как ii — «тоже фидо».

а там и до нормального, векторного и гипертекстового недалеко :-)))

anonymous
()
Ответ на: комментарий от anonymous

Может по аналогии хранить блоками?

ага, BTree и MUMPS (GT.M, например) во все поля. тоже вариант...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.