& ldquo; Используемое пространство & rdquo; изменения после сокращения раздела
Я загрузил свой ноутбук с USB-разъемом Kubuntu 16.04 и использовал KDE Partition Manager (версия 1.2.1), чтобы посмотреть на внутренний жесткий диск (/ dev / sda). Основной раздел (/ dev / sda3, ext4) был равен 442,91 гигабайта, а Partition Manager сообщил, что используется 41.29 GiB.
Затем я использовал KDE Partition Manager для сжатия sda3 до 45 гигабайт. После того, как сжатие было успешно завершено (об ошибках не сообщалось), KDE Partition Manager сообщил, что использовался 35.03 GiB. Данные в разделе не должны были меняться, так как это произошло?
Догадка о том, что Partition Manager фактически дала мне «оценку» используемого пространства, улучшается после операции сокращения; то есть фактические данные всегда были ближе к 35 ГБ. Или, может быть, было удалено много данных в корзине или временных папках. Но это все еще большая разница (около 20 процентов), поэтому мне было интересно, видел ли кто-нибудь это раньше или действительно знает, почему это происходит / ожидается.
Обновление: ноутбук, похоже, загружается и работая после усадки. Разумеется, это не является доказательством, но нет никаких указаний на потерю данных.
Update : количество используемых inodes одинаково между сжатием и unshrunk, а также сравнение контрольной суммы из всех файлов не выявлено различий, поэтому я увереннее, что потери данных не было, что было основной практической проблемой. Вопрос по-прежнему открыт, но более академичен на данный момент.
4 ответа
KDE Partition Manager получает пространство из нескольких источников, некоторые из которых могут быть оценены. Но, как вы сказали, 20% выглядит слишком много.
Я думаю, что еще одна вещь заключается в том, что инструменты изменения размера разделов могут изменять некоторые дисковые структуры, такие как количество экстентов, поэтому вам нужно меньше места для хранения метаданных.
Разница возникает из-за reserved-blocks-percentage, который является параметром файловой системы. [F2] можно изменить с помощью команды tune2fs и имеет значение по умолчанию 5% (см. [F4], найдите -m -описание).
Похоже, что ваш файловая система была отредактирована до 2% перед редактированием раздела и была изменена на 5% при изменении размера.
KDE Partition Manager получает пространство из нескольких источников, некоторые из которых могут быть оценены. Но, как вы сказали, 20% выглядит слишком много.
Я думаю, что еще одна вещь заключается в том, что инструменты изменения размера разделов могут изменять некоторые дисковые структуры, такие как количество экстентов, поэтому вам нужно меньше места для хранения метаданных.
-
1Являются ли экстенты связанными с фрагментацией (вот что я собрал после быстрого поиска)? Есть ли простой способ проверить гипотезу метаданных (чисто из интереса)? У меня есть монтируемые gddrescue изображения как unshrunk, так и сокращенного раздела, и они, похоже, работают. – Ratler 11 February 2018 в 21:51
-
2Вы можете попробовать играть с dumpe2fs и посмотреть, сможете ли вы получать информацию метаданных. Я не заглядывал в то, что экстенты находятся в техническом смысле, поэтому мои знания похожи на ваши после быстрого поиска. – Andrius Štikonas 12 February 2018 в 01:35
-
3Мне удалось повредить промежуточный файл, поэтому он не может использовать его для сравнения. Сравнивая необрезанные и сжатые изображения с dumpe2fs, я не мог видеть ничего, что могло бы объяснить эту разницу (например, inodes или зарезервированные блоки GDT нигде не приближаются к размеру разницы). – Ratler 9 March 2018 в 14:45
Разница возникает из-за reserved-blocks-percentage, который является параметром файловой системы. [F2] можно изменить с помощью команды tune2fs и имеет значение по умолчанию 5% (см. [F4], найдите -m -описание).
Похоже, что ваш файловая система была отредактирована до 2% перед редактированием раздела и была изменена на 5% при изменении размера.
-
1Я проверил, и у unshrunk и shrunk есть ровно 5% зарезервированных блоков (около 22 GiB и 1.9 GiB соответственно). Сохранятся ли зарезервированные блоки в качестве используемого пространства? – Ratler 9 March 2018 в 14:48
-
2Я думал, что вы можете что-то там, но цифры все равно не складываются: если в полном разделе было около 22 GiB в зарезервированных блоках, и это изменилось примерно до 2.2 GiB после первой операции усадки, это позволило бы освободить около 20 GiB пространства, что намного больше, чем изменение 6 GiB, которое я видел (если только только часть зарезервированных блоков не объявлена как «используемое пространство» ...). – Ratler 9 March 2018 в 14:57
-
3@Ratler Да, зарезервированные блоки будут отображаться как используемое пространство. Я думаю, что ваша файловая система была установлена на 2% перед изменением размера, но мы не можем проверить это уже, размер раздела уже изменен ... – mook765 9 March 2018 в 16:46
-
4Перед изменением размера я сделал резервное изображение раздела. Вот как я могу проверить количество заблокированных блоков: 5805286 (~ 22,2 гигабайт) для unshrunk раздела и 498072 (~ 1,9 GiB) для сокращенного раздела. (Я случайно испортил изображение промежуточного раздела, поэтому я не могу проверить напрямую, но на основании двух других нет оснований полагать, что это будет что-то, кроме 5%.) – Ratler 9 March 2018 в 17:27
-
5Я не знаю, как вы проверяете параметры файловой системы, которая находится в файле образа. Однако попробуйте некоторое тестирование: создайте раздел (или используйте существующий) и поиграйте с процентом зарезервированных блоков, а также проверьте, что сообщает KDE Partition Manger в разных условиях. Вероятно, такой тест помогает вам что-то увидеть. – mook765 9 March 2018 в 23:16