Windows Server 2008 Hyper-V не имеет опции для создания клона существующей виртуальной машины. Однако, это не ознаечает что это невозможно или что это сложно сделать. В действительности такая возможность есть и она довольно проста в применении.

Существуют два способа клонировать виртуальную машину в Hyper-V.

1. Использовать функцию эскпорта/импорта виртуальных машин
2. Скопировать виртуальный жесткий диск и создать новую виртуальную машину с этим диском.

1. Используем функцию эспорта/импорта в Hyper-V

Данный способ наиболее простой и доступный путь клонировать виртуальную машину.

Экспорт виртуальной машины

Находясь Hyper-V Manager, нажмите правой кнопкой на нужную виртуальную машину и выберите Export. Укажите куда будет импортирована виртуальная машина. При этом важно знать, что когда вы будете импортировать виртуальную машину обратно, само местоположение виртуальной машины и её виртуального диска будут указывать на данное место.

Во время экпорта вы можете выбрать что экспортировать: целиком виртуальную машину или только конфигурацию виртуальной машины.

Импорт виртуальной машины

Для импорта виртуальной машины нажмите “Import Virtual Machine” из меню Action . Укажите директорию с экспортированной виртуальной машиной и нажмите Import.

Вадно указать именно директорию экспортированной машины, а не одну из её поддиректорий.

После того как виртуальная машина импортирована, вы можете изменить её настройки, к примеру IP адрес, имя хоста и т.д.

2. Копируем VHD и создаем новую виртуальную машину

Просто скопируйте VHD файл оригинальной виртуальной машины и потом создайте новую виртуальную машину, но в качестве жесткого диска укажите скопированный файл. В меню, когды вы дойдете до окна “Connect Virtual Hard Disk” , выберите опцию “Use an existing virtual Hard Disk” и укажите его местоположение.

Постовой

Китайское - не всегда значит плохое. Здесь продаются китайские фронтальные погрузчики по ценам завода-производителя.

Нужен забор для дачи, коттеджа, дома? Обращайтесь в "Профзабор" - изготовление заборов на заказ из любых материалов.

Переустановка операционной системы или смена компьютерного устройства не означает конец работы с установленными гостевыми ОС в программе . Правда, исключением может быть случай, когда файлы жёстких дисков виртуальных машин находятся на системном диске компьютера, а саму систему невозможно восстановить после критического сбоя. Чтобы продолжить работу с имеющимися гостевыми ОС с сохранением их состояния, но уже на переустановленной Windows или на другом компьютере, в арсенале программы VirtualBox имеется инструмент экспорта конфигурации существующих виртуальных машин для его импорта в дальнейшем. Другая возможность продолжить работу с существующими гостевыми ОС — добавление новых виртуальных машин на базе имеющихся файлов их жёстких дисков. Все эти процессы и рассмотрим ниже.

1. Универсальный формат файла экспорта виртуальных машин

Конфигурация существующей виртуальной машины VirtualBox экспортируется в файл «.ova ». Файл «.ova» (Open Virtual Appliance) – это универсальный файл хранения данных виртуальной машины, который можно использовать в различных программах для виртуализации операционных систем. Это , . Экспортированная в этот файл виртуальная машина может быть затем импортирована как программой VirtualBox, так и VMware Workstation или Microsoft Hyper-V в рамках поддерживаемых этими программами гостевых систем.

Рассмотрим детальнее процесс экспорта и импорта конфигурации виртуальной машины VirtualBox в основной системе Windows.

2. Экспорт виртуальной машины

В окне VirtualBox выбираем конкретную виртуальную машину для экспорта, жмём меню «Файл » и выбираем «Экспорт конфигураций ».

В следующем окне жмём «Next ».

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

Далее появится окно параметров экспорта. Формат оставляем предустановленный, а вот папку файла экспорта «.ova», по умолчанию располагающуюся на системном диске, меняем на папку, например, как в нашем случае, специально созданную на несистемном диске D.

В следующем окне жмём «Экспорт ».

Дожидаемся завершения процесса экспорта.

Экспортированная виртуальная машина в файле «.ova» будет находиться в указанной папке, откуда её можно переместить на другой компьютер, съёмный носитель, в облачный сервис. Или можно оставить, как в нашем случае, на месте — на несистемном диске, где этот файл будет храниться во время переустановки Windows.

3. Импорт виртуальной машины

После инсталляции VirtualBox на новой Windows или на другом компьютере открываем программу и в меню «Файл » выбираем «Импорт конфигураций ».

В следующем окне указываем путь к файлу «.ova» с экспортированной виртуальной машиной. Жмём «Next ».

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

Дожидаемся завершения процесса импорта.

После чего увидим импортированную виртуальную машину в списке машин VirtualBox. Что и осталось теперь, так это запустить машину.

Гостевая ОС запустится точно в том состоянии, в котором она была на момент экспорта виртуальной машины.

4. Добавление новой машины из существующего файла жёсткого диска VirtualBox

Альтернатива экспорту и импорту виртуальной машины – добавление новой машины из существующего файла жёсткого диска VirtualBox «.vdi ». Этот способ ничем не уступает процедуре экспорта и импорта виртуальной машины. Более того, если файл «.vdi» расположен на несистемном диске, при переустановке Windows на физическом компьютере можно даже и не тратить время на экспорт конфигурации. Хранящийся же на системном диске файл «.vdi» можем просто перенести на несистемный диск. По большому счёту, процесс экспорта и импорта виртуальной машины выигрывает только экономией занимаемого места файлом «.ova». Например, в нашем случае проводился экспорт виртуальной машины с установленной гостевой ОС Windows ХР, и вес файла «.ova» на выходе составил 4,11 Гб. В то время как размер файла жёсткого диска «.vdi» этой же системы составляет 10 Гб .

Такая выгода в экономии места может быть актуальной в случае переноса виртуальной машины на другой компьютер с помощью облачных хранилищ или съёмного носителя с ограниченным размером. В нашем случае, когда речь идёт именно о переустановке Windows, вполне подойдёт способ добавления новой машины из существующего файла жёсткого диска VirtualBox.

Запускаем VirtualBox и жмём «Создать ».

Задаём показатель оперативной памяти. Жмём «Next ».

В окне выбора жёсткого диска выбираем параметр «Использовать существующий жёсткий диск », с помощью кнопки обзора указываем путь хранения файла «.vdi». Жмём «Создать ».

Виртуальная машина появится в списке VirtualBox, можем её запускать.

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

Добавление новой виртуальной машины из существующего файла «.vdi» – это также способ перенести файл жёсткого диска гостевой ОС на несистемный диск компьютера, если изначально таковой был создан на системном диске, и со временем занимаемое им место стало снижать производительность системы. Для этого необходимо удалить виртуальную машину из списка в главном окне VirtualBox. На выбранной машине вызываем контекстное меню и выбираем «Удалить ».

Затем в появившемся окошке жмём «Убрать из списка ».

После этого можно искать файл жёсткого диска «.vdi» на системном диске (как правило, по умолчанию это путь C:\Users\Имя_пользователя\VirtualBox VMs ), переносить его на несистемный диск и добавлять виртуальную машину заново.

Помогла ли Вам данная статья?

Аннотация: Целью данной практической работы является подробное рассмотрение процессов экспорта и импорта виртуальных машин стандартными средствами Hyper-V и понятие снимок виртуальной машиной.

Экспорт виртуальной машины

Примечание. Материал практики основан на разделе "Local Desktop Virtualization" книги "Understanding Microsoft Virtualizations Solutions" M. Tulloch (Chapter 2).

Процесс экспорта виртуальной машины средствами Hyper-V не составляет труда. Единственный параметр , который необходимо определить - путь сохранения файлов виртуальной машины. Для экспорта ВМ необходимо:

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

На следующем рисунке представлено содержимое папки экспортированной виртуальной машины:

Рис. 10.3.

Config.xml - файл , содержащий информацию об исходном местоположении файлов виртуальных жестких дисков экспортируемой машины.

В папке Virtual Machines находится .exp файл , содержащий сведения об экспортированной виртуальной машине. В ходе импорта данный файл преобразуется в конфигурационный xml - файл .

В папке Virtual Hard Disks находятся файлы виртуальных жестких дисков экспортированной машины.

В папке Snapshots содержит сведения о моментальных снимках виртуальной машины (.avhd , .vsv , .bin ).

Импорт виртуальной машины

Отметим особенности импорта виртуальных машин Hyper - V:

1. Импортировать в Hyper-V можно только виртуальные машины другого Hyper-V сервера. Импорт виртуальных машин Virtual PC или Virtual Server невозможен, поскольку конфигурация виртуальных машин, создаваемых этими решениями отличается от Hyper-V, несмотря на то, что все решения используют .vhd - файлы виртуальных жестких дисков.
2. Виртуальную машину можно экспортировать только один раз. Как уже отмечалось, создаваемый при экспорте .exp - файл сведений о виртуальной машине, в процессе импорта преобразуется в xml - файл конфигурации. В связи с этим, при возникновении ошибок импорта единственным способом продолжения работы с импортируемой виртуальной машиной является создание новой с аналогичной конфигурацией на основе уже имеющихся файлов виртуальных жестких дисков.

Для импорта виртуальной машины необходимо:

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

Снимки виртуальной машины (snapshot)

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

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

Для создания снимка необходимо выбрать пункт Снимок выпадающего меню .

Рис. 10.7.

После создания снимка появится соответствующий значок на панели "Снимки" диспетчера Hyper-V.

Для возврата виртуальной машины к состоянию снимка, необходимо применить его к виртуальной машине (см. рис. 10.9).

Рис. 10.9.

Как показано на рис. 10.9 , доступны следующие действия работы со снимками:

• Применить - скопировать состояние виртуальной машины из выбранного снимка в активную виртуальную машину. При этом виртуальная машина возвращается к состоянию, описанному в выбранном снимке. Все несохраненные данные в активной виртуальной машине будут потеряны.
• Переименовать - команда позволяет изменения имени моментального снимка.
• Удалить снимок - команда удаления файлов, связанных с выбранным снимком, файлы других снимков затронуты не будут. При удалении текущее состояние активной виртуальной машины не меняется.
• Удалить дерево снимков - позволяет удалить выбранный моментальный снимок и все снимки, иерархически подчиненные ему. При удалении текущее состояние активной виртуальной машины не меняется.

Краткие итоги.

В рамках данной практики были рассмотрены возможности Hyper-V для экспорта и импорта виртуальных машин, а также по созданию снимков состояния виртуальной машины. Функции экспорта и импорта используются для переноса виртуальной машины с одного Hyper-V сервера на другой.

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

---
Команда Яндекс.Диска,
помогаем сохранить важное ","html":"

Для Windows и Mac OS X появилась важная функция - выборочная синхронизация. Теперь вы можете выбирать, какие папки хранить на компьютере, а какие - только на Яндекс.Диске.

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

Если вы используете Диск на нескольких компьютерах, синхронизацию отдельных папок можно включить на одном из них и выключить на другом. К примеру, личный фотоархив можно хранить на домашнем компьютере, чтобы он не занимал место на рабочем. А общие папки держать только на рабочем ноутбуке, чтобы не было соблазна поработать с ними из дома.

Управление синхронизацией папок доступно в настройках приложений.

---
Команда Яндекс.Диска,
помогаем сохранить важное

","contentType":"text/html"},"proposedBody":{"source":"

Для Windows и Mac OS X появилась важная функция - выборочная синхронизация. Теперь вы можете выбирать, какие папки хранить на компьютере, а какие - только на Яндекс.Диске.

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

Если вы используете Диск на нескольких компьютерах, синхронизацию отдельных папок можно включить на одном из них и выключить на другом. К примеру, личный фотоархив можно хранить на домашнем компьютере, чтобы он не занимал место на рабочем. А общие папки держать только на рабочем ноутбуке, чтобы не было соблазна поработать с ними из дома.

Управление синхронизацией папок доступно в настройках приложений.

---
Команда Яндекс.Диска,
помогаем сохранить важное

Для Windows и Mac OS X появилась важная функция - выборочная синхронизация. Теперь вы можете выбирать, какие папки хранить на компьютере, а какие - только на Яндекс.Диске.

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

Если вы используете Диск на нескольких компьютерах, синхронизацию отдельных папок можно включить на одном из них и выключить на другом. К примеру, личный фотоархив можно хранить на домашнем компьютере, чтобы он не занимал место на рабочем. А общие папки держать только на рабочем ноутбуке, чтобы не было соблазна поработать с ними из дома.

Управление синхронизацией папок доступно в настройках приложений.

---
Команда Яндекс.Диска,
помогаем сохранить важное

","contentType":"text/html"},"authorId":"120228024","slug":"57789","canEdit":false,"canComment":false,"isBanned":false,"canPublish":false,"viewType":"old","isDraft":false,"isSubscriber":false,"commentsCount":164,"modificationDate":"Tue Jan 29 2013 12:13:00 GMT+0000 (UTC)","showPreview":true,"approvedPreview":{"source":" для Windows и Mac OS X появилась важная функция - выборочная синхронизация. Теперь вы можете выбирать, какие папки хранить на компьютере, а какие - только на Яндекс.Диске.","html":"В приложениях Яндекс.Диска для Windows и Mac OS X появилась важная функция - выборочная синхронизация. Теперь вы можете выбирать, какие папки хранить на компьютере, а какие - только на Яндекс.Диске.","contentType":"text/html"},"proposedPreview":{"source":" для Windows и Mac OS X появилась важная функция - выборочная синхронизация. Теперь вы можете выбирать, какие папки хранить на компьютере, а какие - только на Яндекс.Диске.","html":"В приложениях Яндекс.Диска для Windows и Mac OS X появилась важная функция - выборочная синхронизация. Теперь вы можете выбирать, какие папки хранить на компьютере, а какие - только на Яндекс.Диске.","contentType":"text/html"},"titleImage":null,"tags":[{"displayName":"Диск","slug":"disk","categoryId":"120469667","url":"/blog/company??tag=disk"}],"isModerator":false,"commentsEnabled":true,"url":"/blog/company/57789","urlTemplate":"/blog/company/%slug%","fullBlogUrl":"https://yandex.ru/blog/company","addCommentUrl":"/blog/createComment/company/57789","updateCommentUrl":"/blog/updateComment/company/57789","addCommentWithCaptcha":"/blog/createWithCaptcha/company/57789","changeCaptchaUrl":"/blog/api/captcha/new","putImageUrl":"/blog/image/put","urlBlog":"/blog/company","urlEditPost":"/blog/56288d577eba6ef16f808526/edit","urlSlug":"/blog/post/generateSlug","urlPublishPost":"/blog/56288d577eba6ef16f808526/publish","urlUnpublishPost":"/blog/56288d577eba6ef16f808526/unpublish","urlRemovePost":"/blog/56288d577eba6ef16f808526/removePost","urlDraft":"/blog/company/57789/draft","urlDraftTemplate":"/blog/company/%slug%/draft","urlRemoveDraft":"/blog/56288d577eba6ef16f808526/removeDraft","urlTagSuggest":"/blog/api/suggest/company","urlAfterDelete":"/blog/company","isAuthor":false,"subscribeUrl":"/blog/api/subscribe/56288d577eba6ef16f808526","unsubscribeUrl":"/blog/api/unsubscribe/56288d577eba6ef16f808526","urlEditPostPage":"/blog/company/56288d577eba6ef16f808526/edit","urlForTranslate":"/blog/post/translate","urlRelateIssue":"/blog/post/updateIssue","urlUpdateTranslate":"/blog/post/updateTranslate","urlLoadTranslate":"/blog/post/loadTranslate","urlTranslationStatus":"/blog/company/57789/translationInfo","urlRelatedArticles":"/blog/api/relatedArticles/company/57789","author":{"id":"120228024","uid":{"value":"120228024","lite":false,"hosted":false},"aliases":{},"login":"anyksenya","display_name":{"name":"anyksenya","avatar":{"default":"21377/120228024-6941905","empty":false}},"address":"[email protected]","defaultAvatar":"21377/120228024-6941905","imageSrc":"https://avatars.mds.yandex.net/get-yapic/21377/120228024-6941905/islands-middle","isYandexStaff":false},"originalModificationDate":"2013-01-29T08:13:52.000Z","socialImage":{"orig":{"fullPath":"https://avatars.mds.yandex.net/get-yablogs/49865/file_1465551301378/orig"}}}}}">

Выборочная синхронизация папок на Яндекс.Диске

---
Команда Яндекс.Диска,
помогаем сохранить важное

Алгоритмы ,

Разработка веб-сайтов

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

В этом посте я расскажу, почему так получилось: чего мы не смогли предвидеть, когда придумывали первую версию ПО Яндекс.Диска, и как создавали новую.

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

Почему это не так просто, как кажется на первый взгляд?

Теоретически задача может показаться достаточно простой, но в реальности мы сталкиваемся с разными сложными ситуациями. Например, человек переименовал папку на своем компьютере, мы это детектировали и послали команду на бекенд. Однако никто из пользователей не ждет, пока бекенд подтвердит успешность переименования. Человек сразу открывает свою локально переименованную папку, создает в ней подпапку, и, к примеру, переносит в нее часть файлов. Мы попали в ситуацию, в которой невозможно сразу выполнить все необходимые операции синхронизации в облаке. Сначала надо дождаться завершения первой операции и только потом можно продолжать.

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

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

Прошлая версия алгоритма

В прошлой версии десктопного ПО Яндекс.Диска для поиска изменений использовался алгоритм сравнения деревьев. Любое другое решение на тот момент не позволяло реализовать поиск перемещений и переименований, так как бэкэнд не имел уникальных идентификаторов объектов.

В этой версии алгоритма мы использовали три основных дерева: локальное (Local Index), облачное (Remote Index) и последнее синхронизированное (Stable Index). Кроме этого, чтобы предотвратить повторную генерацию уже поставленных в очередь операций синхронизации, использовались ещё два вспомогательных дерева: локальное ожидаемое и облачное ожидаемое (Expected Remote Index и Expected Local Index). В этих вспомогательных деревьях хранилось ожидаемое состояние локальной файловой системы и облака, после выполнения всех операций синхронизации, которые уже поставлены в очередь.

Процедура сравнения деревьев в старом алгоритме выглядела следующим образом:

1. Если локальное ожидаемое дерево и облачное ожидаемое дерево пусты, инициализируем их, копируя последнее синхронизированное дерево;
2. Сравниваем локальное дерево с облачным ожидаемым и по результатам сравнения отдельных узлов добавляем в очередь операции синхронизации в облаке (создание коллекций, передача файлов в облако, перемещение и удаление в облаке);
3. Для всех операций, которые поставлены в очередь на предыдущем шаге, фиксируем их будущий эффект в ожидаемом облачном дереве;
4. Сравниваем облачное дерево с локальным ожидаемым и по результатам сравнения отдельных узлов добавляем в очередь операции синхронизации с локальной файловой системой (создание директорий, скачивание файлов из облака, перемещение и удаление локальных файлов и директорий);
5. Для всех операций, которые поставлены в очередь на предыдущем шаге, фиксируем их будущий эффект в ожидаемом локальном дереве;
6. Если в очередь попадают одновременные операции с одним и тем же файлом или директорией (например, передача файла в облако и скачивание этого же файла из облака), то фиксируем конфликт - файл изменился в двух местах;
7. После того, как операция синхронизации выполнена в облаке или с локальной файловой системой, заносим её результат в последнее синхронизированное дерево;
8. Когда очередь операций синхронизации становится пустой, удаляем локальное ожидаемое и облачное ожидаемое дерево. Синхронизация закончена, и они нам больше не понадобятся.

Почему нам пришлось придумывать новый алгоритм

Главными проблемами алгоритма сравнения деревьев стали большое потребление памяти и необходимость сравнения деревьев целиком даже при небольших изменениях, что приводило к большой нагрузке на процессор. Во время обработки изменений даже одного файла использование оперативной памяти возрастало примерно на 35%. Допустим, у пользователя было 20 000 файлов. Тогда при простом переименовании одного файла размером 10Кб потребление памяти вырастало скачкообразно - со 116Мб до 167МБ.

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

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

К этому времени на бекенде появились id объектов, с помощью которых можно было более эффективно решить задачу обнаружения перемещений - ранее мы использовали пути.

Новый алгоритм

Мы решили изменить структуру хранения данных и заменить три дерева (Local Index, Remote Index, Stable Index) на одно, что должно было привести к снижению избыточности в главной структуре данных. Из-за того что ключом в дереве является путь к элементу файловой системы, в результате объединения значительно сократился объем используемой оперативной памяти.

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

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

1. После того как пользователь добавил в папку Диска новый файл, программа обнаружила его и добавила в дерево новый элемент. У этого элемента известно только одно состояние – local. Так как stable и remote состояния отсутствуют, память под них не выделяется;
2. Программа выполняет upload файла. Из облака приходит push, подтверждающий появление нового файла, и в дерево добавляется remote состояние;
3. Состояния local и remote сравниваются. Так как они совпадают, добавляется stable состояние;
4. Состояния local и remote удаляются. Они больше не нужны, так как вся информация есть в stable.

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

Другие улучшения

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

Яндекс.Диск использует дайджесты sha256 и MD5 для проверки целостности файлов, обнаружения изменившихся фрагментов и дедупликации файлов на бекенде. Так как эта задача сильно нагружает CPU, в новой версии реализация расчетов дайджеста была существенно оптимизирована. Скорость получения дайджеста файла увеличена примерно в два раза.

Цифры

Синхронизация уникальных 20000 файлов по 10Кб

Вычисление дайджестов уникальных 20000 файлов по 10кб (индексация)

Запуск с 20000 синхронизированных файлов по 10Кб

Upload 1Gb. Соединение Wi-Fi 10 МБит
Время, сек

Что получилось

Из примеров видно, что новая версия ПО Яндекс.Диска использует примерно в 3 раза меньше оперативной памяти и примерно в 2 раза меньше нагружает CPU. Обработка мелких изменений не приводит к увеличению объема используемой памяти.

В результате проделанных изменений существенно увеличилось количество файлов, с которым без проблем справляется программа. В версии для Windows – 300 000, а на Mac OS X - 900 000 файлов.