klink0v (klink0v) wrote,
klink0v
klink0v

Category:

Странная работа Яндекс.Диска

Про Яндекс.Диск слышали, наверное, все. Но я, как настоящий граблеискатель, решил попробовать использовать его немного в непроектных режимах. А конкретно, попробовать запихнуть туда TrueCrypt-контейнер максимально возможного объема, а именно 10 Гб.

Почему именно Яндекс.Диск? Как показала серия экспериментов, он один из немногих корректно отрабатывает изменение небольшого кусочка в большом файле и закачивает только ту самую delta (разницу), весьма существенно экономя при этом трафик. Другими словами, работает по принципу rsync-а. Разумеется, я имею в виду штатную программу-клиента. Во-вторых, он устанавливает весма гуманное ограничение на максимальный размер одного файла (10 Гб). В-третьих, для российского сегмента Сети он обладает максимальной скоростью каналов, то есть работает быстрее любых своих конкурентов.

Зачем TrueCrypt? Да параноик я. Всё таки боюсь я выкладывать в открытом виде хоть сколько-нибудь ценные документы на ресурс, который администрирую не я.

Сперва я попробовал проделать эксперимент на контейнере размером 1 Гб, при этом на Яндекс.Диске было 10 Гб свободного места. Всё прошло гладко. После редактирования тестового зашифрованного текстового документа на сервер было отослано в общей сложности около 1 Мб данных из файла-контейнера, что можно считать вполне достойным результатом.

Но когда я создал контейнер размером 10 Гб, вот тут начались чудеса. Создался он без проблем. Закачался на сервер тоже без проблем. Но после внутренних изменений клиент рассчитал контрольные суммы, а вот дальше почему-то ничего не произошло. Программа осталась пребывать в состостоянии "вечной синхронизации". При попытке же принудительно остановить её, а затем запустить заново, она начала ругаться на отсутствие свободного места, несмотря на то, что реально там оставалось еще мегабайт четыреста. Хуже того, даже после того как я удалил контейнер и с десктопа, и с сервера (через веб-интерфейс), программа-клиент продолжлила индицировать, что места на сервере больше не осталось и отказывалась что-либо делать, в то время как веб-клиент всё показывал правильно.

Забегая вперёд, могу сказать, что я всё равно отказался от идеи хранить 10-гигабайтный TrueCrypt-контейнер на Яндекс.Диске, ибо на Core2Duo частотой 2ГГц время перерасчета контрольных сумм для экспериментального файла составляет около 15 минут, что неприемлемо долго. Причем, процесс почему-то не распараллеливается на несколько ядер (хотя по-хорошему мог бы). Но тем не менее, явно, что штатный клиент всё равно несколько "сыроват". От больших файлов ему что-то конкретно "сносит крышу". Так что буду теперь смотреть в сторону BoxCryptor.

Если вдруг разработчики сабжа чисто случайно прочитают мой блог, то у меня есть к ним несколько вопросов.

  • Почему вы не используете .NET Framework? С ней очень хорошо реализуется кросплатформенность применительно к Windows-системам и распараллеливание математических операций по нескольким ядрам процессора.
  • Почему вы с самого начала не предусмотрели возможности использования более чем одного ядра CPU?
  • Как устроены алгоритмы на серверной стороне? Верно ли моё подозрение, что для того чтобы успешно сохранить изменение delta в файле размером N Байт, надо обязательно фактически иметь N+delta байт свободного места на Яндекс.Диске?
  • Вы вообще тестировали работу Яндекс.Диска на очень больших файлах и/или в ситуациях, когда свободного места меньше, чем суммарный размер внесенных на какой-то итерации изменений?

А так, конечно, вполне себе достойное начинание и широкий жест доброй воли по отношению к пользователям. В конце концов, протокол открыт и есличо, то принцип "DIY" никто не отменял.

Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

  • 8 comments