Обсуждение ПО для работы с разделами

[9285]

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



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

[Smirnoff]

Цитата (9285) »

пока что не встречал чтобы делалось сжатие с конца а потом сдвиг.

Подлый Acronis True Image при клонировании (клонировании! балин) норовит сначала скопировать все разделы так, как он сам считает "правильным", а уже потом начинает изменять размеры разделов на те, что были указаны пользователем - при этом, заодно уж, ещё и данные перемещает.
Так что я не буду сильно удивлён...

[9285]

Smirnoff
Помнится мы это обсуждали в другом месте. И, насколько помню, я проводил моделирование ситуации и припоминается что в самом начале реально копируется раздел - но именно раздел (то есть запись в РТ) а том уже клонируется в раздел.
Впрочем, если даже наоборот, то в этом для меня нет ничего нового, в том числе и в перемещении данных (о которых написал выше).
К сожалению, я не знаю есть ли возможность каким то образом отследить всё делаемое акронисом чтобы понять его "алгоритмы" - поэтому выводы делаются опосредованно. Но если бы такая возможность бы была - наверняка шок был бы более существенным.

[Smirnoff]

Цитата (9285) »

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

Если сам ATI внятно пишет название этапа "изменение размера раздела с перемещением данных"...

[9285]

Smirnoff
Когда акронис начинает деструкцию появляется кнопка на которой написано "Отмена" - верить написанномуи то произойдёт отмена того что сделано? Вопрос риторический.
А если серьёзно, то написанное программой можно понимать по разному. Ведь по любому размер раздела изменяется и данные на расположенные в пределе сжимаемого обьема по любому перемещаются. Так что название можно посчитать и корректным. Тем более что речь идёт о небольшом перемещении данных - а ведь можно понять как будто сначала клонируется оригинал, а потом уже сжимается.
А если ещё и перемещается весь, так то и времени должно быть немало - а в моём эксперименте прошло достаточно быстро.
В любом случае это лишь догадки, основанные логикой, интуицией и имеющимся сведениям. Вот есди бы при этих действиях использовался функционал журналирования ФС, то было бы легче поят - да и безопасней само преобразоване (в случае NTFS).

[Smirnoff]

Цитата (9285) »

написанное программой можно понимать по разному.

Ну... сначала-то ATI пишет "копирование раздела" - и это продолжается как раз примерно столько, сколько и должно продолжаться копирование объёма данных. А вот следующими этапами (после всех копирований всех разделов) бывают как раз этапы "изменение размеров с перемещением данных".

СПОЙЛЕР »

Цитата (9285) »

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

Если мы продолжаем говорить про ATI... Вот смотри: на оригинале был раздел 64 гига под винду и остаток от 250 - под данные. Я клонирую на терабайтный диск, не вмешиваясь в размеры разделов на клоне - ATI бодренько копирует разделы (без всяких там "изменений разделов") и получается раздел 256 под винду и остальное - под данные. Если сказать, что на клоне размер раздела под винду будет 128 гигов - стадии "изменение разделов" будут обязательно - но пройдут очень быстро; ибо реально никакие пользовательские данные двигать будет не надо; просто изменить размер одного раздела с 256 до 128 и сдвинуть начало второго раздела - это, кстати, прекрасно видно потом на картинке, например, Auslogics Disk Defrag - в начале второго раздела будет пустое место около ~128 гигов. Но вот если заказать первый раздел не те 256, в которые его изначально склонирует ATI, а 512 - этап "изменения с перемещением" будет идти почти столько-же, сколько шло изначальное копирование.
Из этого я и делаю вывод, что ATI сначала копирует разделы в тот размер, который считает "правильным", а уже потом на копии начинает таскать туда/сюда данные вместе с изменением размеров разделов на заказанные перед началом клонирования.
И как раз это я тогда указывал в качестве дебильного недостатка ATI - при том, что гораздо более ранние версии Norton и Symantec Ghost при клонировании разделов с изменением размера никаких-таких "перемещений" не затевали - просто сразу создавали на приёмнике разделы заданных размеров и уже в них копировали информацию с исходника...

[9285]

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

СПОЙЛЕР »

У меня вообще убеждение что есть кучка разработчиков, каждый из которых пишет определённую операцию, и есть кто то, кто собирает пазл из всего этого. При этом чтобы не тратить время на разработку новых операций используются старые, но "обработанные" новыми корректировщиками.
Вот лично я только таким могу обьяснить что делаются конструкции типа той, о которой писал раньше. То есть один модуль создаёт раздел по старым стандартам разметки (например с началом в секторе 63) а потом другой "выравнивает" но не изменяя значение в РТ а просто делая промежуточную таблицу). А "л раздел

[9285]

Smirnoff
На всякий случай - в какой версии происходят такие перемещения? Запуск делается с бутявки или из винды?

[Smirnoff]

Цитата (9285) »

в какой версии происходят такие перемещения?

ATI 2016 сборка 5634; сборку ATI 2014 не помню и лениво искать флешку с ней...

Цитата (9285) »

Запуск делается с бутявки или из винды?

С бутявки.

[9285]

Smirnoff
ATI 2018, Build 10410, BootCD
Запустил клонирование и в ручном режиме уменьшил размер первого (не считая начального служебного) раздела, а второй растянул на освободившееся место.
На клоне, что метафайлы, что данные оказались на поляне, которая за пределами размеров исходного диска.
Могу приложить скриншоты, хотя наверное и так понятно что в данном случае нельзя говорить о каких то алгоритмах (тем более стабильных) - делается по принципу "пальцем в небо".
При этом усложняется перечень действий - вот смысл пересчитывать всю MFT если можно банально всё скопировать?

[Smirnoff]

Цитата (9285) »

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

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

Цитата (9285) »

вот смысл пересчитывать всю MFT если можно банально всё скопировать?

Norton Ghost и, потом, Symantec Ghost именно так и делали: сначала создавали на приёмнике разделы заданного раздела, потом копировали туда информацию с исходных разделов.
А вот Acronis... они альтернативные такие.

Добавлено через 1 минуту

Цитата (9285) »

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

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

[9285]

Цитата (Smirnoff) »

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

СПОЙЛЕР »

Что то я не очень понял эту "задачку".
Подразумеваешь что в область на которую расширяется начало тома ничего не должно попасть?
Для простоты анализа эксперименты проводятся на небольших размерах и (если нет такой необходимости) с минимумом данных на томе.
Но, в любом случае, на клоне сделанном по такому условию задачи как минимум журнал файловой системы и битовая карта тома оказались в самом начале тома - то есть на участке расширения относительно предложенной акронисом).

[Smirnoff]

Цитата (9285) »

Что то я не очень понял эту "задачку".

Ты внимательно прочитал мой текст под спойлером в сообщении после манипуляций с Acronis Disc Director скрылись файлы на диске D#26 ?

[9285]

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

[Smirnoff]

Цитата (9285) »

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

Так я и не говорил, что ATI метафайлы не перемещает...

[9285]

Smirnoff
Зато ты писал что в начале раздела пустое место. А в ауслоджике метафайлы отображаются на общей карте и не выделяются отдельным цветом - то есть не заметить их сложно.
Да и чуть выше я написал про метафайлы и данные а ты при ответе написал ОНИ.
Ну да ладно, это не столь критично - забью раздел данными под завязку и посмотрю как будет в этом случае.

Добавлено через 3 минуты

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

[Smirnoff]

Цитата (9285) »

смысл перетаскивать метафайлы

Этот вопрос следовало бы Acronis задать...

[9285]

Smirnoff
Задавать вопросы им бесполезно.

СПОЙЛЕР »

Давно, на хоботе, было одно обсуждение в котором участвовал сотрудник акрониса.
Было там и обвинения пользователей в криворукости и много чего ещё - только не признание того что программа сделана через одно место. Когда же началось небольшое понимание этого, то почти сразу всё прекратилось. Уже в личной переписке было сказано что руководство не одобрило эти порывы сотрудника.
На осзоне где то есть в теме упоминание какого то серьёзного косяка и нулевую реакцию (ещё точнее - игнорирование её). По большому счёту наличие всевозможных "мин замедленного действия" и т.п. выгодно для развития их же бизнеса:
- Косячит ADD или выключили свет при ресайзе?
- Забэкапься!
- Как чем?
- Конечно же ATI!

А то, что ресайз, причём длительный делался в случае когда можно обойтись 1 секундой - ну так об этом же лохи не догадываются. Как и не догадываются о том, что можно сделать это безопасно или с подстраховкой (как в том же парагоновском менеджере).

[9285]

Smirnoff
Новый эксперимент проводил в "твоей" версии ATI (*) и подтвердилось написанное тобой. То есть акронис сначала делает структуру и записывает разделы в границах, которые "придумал" он а потом уже ресайзит - причём в случае второго раздела, во всех случаях, в начало тома перенесены журнал ФС и битовая карта тома.
Причём, судя по началу данных в "придуманном" начале тома, структура их соответствует оригиналу (даже процент фрагментации ауслоджик выдаёт идентичный. Как бы напрашивается мысль что делается что то типа посекторки но без заполнения незанятого пространства, но нет - метафайлы записываются в другие места.

Что имеем в результате.
1. Делается то, что не заказывалось пользователем - то есть то, что сам акронис запланировал но "забыл" отменить.
В принципе, не так страшно если после этого расширение делается лишь за счёт передвижки начала и перемещения пары метафайлов.
но ведь это всё равно приводит к пересчёту MFT. Ну и зачем всё это, тем более что есть повод сомневаться в том что и это может сделаться без косяков (**)
А если при другом расположении звёзд будет решено передвинуть и всё остальное?
Но даже в такой ситуации, по сути закладывается "мина замедленного действия" - если в дальнейшем пользователь решит уменьшить второй том, и решит сделать это безопасно (штатными средствами) винды, то упрётся в то, что ими том не будет уменьшен далее той же MFT. Опять Акронис? но уже ADD у которого свои тараканы и уже он может начать глобальный перенос.

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

[Smirnoff]

Цитата (9285) »

вполне ожидаемое сообщение об ошибке - и именно в записи этого файла, о неправильном дескрипторе безопасности.

А данные-то в этом логе вообще есть?