Имеется жесткий диск 1TB, на нем один NTFS раздел (занимает весь диск), свободно около 150GB.
Нужно преобразовать его в EXT4 без потери данных.
Поиск информации на эту тему дал 2 решения:
1. Скопировать все данные на другой жесткий диск и отформатировать полностью в EXT4
2. Уменьшить NTFS раздел на 150GB, создать в освободившемся пространстве EXT4 раздел, перенести первые 150GB на него, затем постепенно уменьшать NTFS раздел и увеличивать EXT4 и понемногу переносить данные
Первый вариант не подходит, т.к. нет свободного терабайта. Второй вариант имеет право на жизнь, однако придется делать минимум 6 итераций, что значительно повышает риски, да и времени уйдет очень много.
Но я верю, что прогресс не стоит на месте и возможно это сделать как-то проще. Я ошибаюсь?
Да вы мне просто глаза открыли. Ваш комментарий наполнен глубинным смыслом, от него исцеляются больные, коровы начинают давать больше молока, а депутаты перестают брать взятки.
Ну серъезно — если данные у вас на диске вы оцениваете меньше чем в 3тыс, то можете эксперементировать, но постепенный переброс у вас если и выйдет, то шанс запороть все очень велик.
Ну и практика показывает, что реально важных данных не так много у людей. вот у вас 750gb неужели только рабочими данными заняты?
Сохраните ваши ценнейшие данные на DVD-болванки. Шпидель с сотней штук стоит в районе 1К. Это 470 Гб. По времени не сильно быстрее замутов с постепенным форматированием, но таки как-то поудобнее, имхо.
Ну хз тогда. Задача в принципе геморройная, крепитесь. А очень надо на Ext4 переезжать? NTFS-3g не так уж и плох. Особенно по сравнению с записью 100 DVD :)
Не родная, но драйвер таки stable. Хотя кончено FUSE, скорость, пилёхо. Я же не предлагаю на постоянку такое решение. Временно откусите от 150 Гб разделы под систему и home, а сторадж пусть будет на NTFS, пока не найдёте буферный винт.
Подружитесь с сервисниками при любом железячном магазине и приходите к ним с линуксовой флешкой и своим винтом с просьбой одолжить док с компом и 150гб на полчасика. Или просто с кем-нибудь, у кого есть 150гб одолжить наполчасика. Банка пива стоит дешевле и записывается быстрее, чем сотня болванок.
второй вариант — не вариант. Во-первых, он дольше, чем найти терабайтник, во-вторых — любой сбой и всё насмарку, а в третьих — ваша ext4 будет в результате ужасно тормозная из-за фрагментации (любая ext* жутко фрагментируется, если работает с заполнением «под завязку», а у вас она в таком режиме работать будет как минимум 6 раз).
Ну почему же насмарку. ФС при сбое операции увеличения размера раздела неплохо восстанавливается. Вероятность, что что-то пойдет не так, конечно же есть, но она невелика.
ваша ext4 будет в результате ужасно тормозная из-за фрагментации
На каждой итерации увеличения ext4 раздела «влево» данные будут перемещаться в начало раздела и дефрагментироваться. Так что, неправда ваша.
Кто сказал, что они будут дефрагментироваться? «Влево» переносится вся ФС, а потом «растягивается» обычным способом. По крайней мере GParted делает так. И если вы скажете что-то про partition magic, я вам не поверю — реально там и в resize2fs один и тот же код, написанный одним и тем же человеком — Теодором Цо, так что и работает он одинаково.
Я не в буквальном смысле имел ввиду. Если я на пустой раздел записываю 150Гб данные имеют минимальную фрагментацию. Затем увеличиваю его «влево», и, как вы сказали, «переносится вся ФС, а потом растягивается обычным способом», соответственно фрагментация должна остаться минимальной.
Итак, рассмотрим сценарий внимательнее.
Мы сделали 150 Гб e4, забили её под завязку. Она фрагментировалась.
Теперь её всю, не изменяя, мы переносим «назад».
Потом мы «растягиваем» её, т.е. добавляем к концу ещё 150 ГБ новых block groups. Теперь у нас ФС выглядит так: 150 ГБ в начале фрагментировано и забито под завязку, а 150 Гб в конце свободно.
Свободное место мы снова забиваем под завязку — при этом занятые части ФС, естественно, никак не меняются, а новые фрагментируются. Процесс повторяется.
В конце концов мы будем иметь 6 независимо заполненных и фрагментированных групп блоков объёмом 150 ГБ каждая. По уровню фрагментации это в шесть раз хуже, чем если бы мы сразу с нуля под завязку забили терабайтник.
Такая ФС однозначно будет тормозить, поскольку потребуются лишние перемещения головок диска и ожидания поворота шпинделя. Вкупе с проблемами I/O в Linux типа пресловутого бага 12309, это приведёт к низкой производительности системы в целом.
Потому что так работает block allocator. Весь диск разбивается на блок-группы (по умолчанию 128 Мб), и каждый файл система старается разместить целиком в одной block group, и пытается выбрать именно ту группу, в которой расположена его inode и директория, и только если block group заполнена — то уже блоки идут в другую.
А теперь представьте, как будут расположены файлы, записанные в почти полную ФС.
