Выходной файл образа DD больше исходного раздела, и DD не хватает места на целевом разделе (где создан образ), несмотря на то, что он больше исходного раздела.
Я пытаюсь скопировать раздел в файл на другом разделе того же диска. Целевой раздел немного больше входного раздела. Оба раздела ext3.
Запускается с OpenSuse-Rescue LIVE CD. Yast показывает, что входной раздел ( sdb1) имеет размер 62,5 ГиБ, а выходной sdb2— 62,85 ГиБ.
Thunar показывает, что размер входных данных sdb1составляет 65,9 ГБ, а выходных sdb2— 66,2 ГБ, при этом выходной ddфайл изображения также имеет размер 66,2 ГБ, так что, очевидно, достигается максимальный размер sdb2.
Вот консоль:
( sdb1был размонтирован, пробовал ddнесколько раз)
linux:# dd if=/dev/sdb1 of=RR.image bs=4096
dd: error writing ‘RR.image’: No space left on device
16156459+0 records in
16156458+0 records out
66176851968 bytes (66 GB) copied, 2648.89 s, 25.0 MB/s
Дополнительная информация по запросу:
И снова: я вижу разницу в размере исходного раздела и созданного из него sdb1файла образа DD . Этот файл находится на .RR.imagesdb2
Здесь все еще есть кое-что неясное: Я ЗАПУСКАЮ DD КАК ROOT, так что зарезервированное пространство доступно для записи, верно? Цель sdb2составляет 62,85 GiB, в то время как общий размер байтов для образа, как вы сказали, составляет около 61,63 GiB. Вот также вывод команд dfи POSIXLY_CORRECT=1 df:
Система теперь system-rescue-cd
root@sysresccd /root % df
Filesystem 1K-blocks Used Available Use% Mounted on
…
/dev/sdb1 64376668 7086884 56241208 12% /media/Data1
/dev/sdb2 64742212 64742212 0 100% /media/Data2
/dev/sdb3 5236728 4785720 451008 92% /usr/local
root@sysresccd /root % POSIXLY_CORRECT=1 df /dev/sdb1
Filesystem 512B-blocks Used Available Use% Mounted on
/dev/sdb1 128753336 14173768 112482416 12% /media/Data1
root@sysresccd /root % POSIXLY_CORRECT=1 df /dev/sdb2
Filesystem 512B-blocks Used Available Use% Mounted on
/dev/sdb2 129484424 129484424 0 100% /media/Data2
Числа будут точно такими же, как и в простом уравнении, dfесли мы разделим их на 2. 1024b/512b=2 — делитель.
sdb1меньше, чемsdb2. 100-процентное использование наsdb2данный момент связано с файлом образа DD, который заполнил раздел. Это должен быть единственный файл на нем сейчас.Сам файл образа составляет 66 176 851 968 байт по состоянию на DD (во время выполнения) и отчеты Thunar. Разделив на 1024 байта, мы получаем 64625832 K-блоков, верно? Так что это все еще меньше, чем
dfсообщалось,sdb2более чем на 116380 КБ и это БОЛЬШЕ, ЧЕМsdb1(ИСТОЧНИК), но он максимизирует разделsdb2.
Вопрос в том, что там есть, чтобы занять это пространство sdb2?
Но самое главное и интересное:
Почему целевой файл больше исходного раздела, ddиз которого он был создан? Для меня это означает: я не могу записать его обратно.
sdb1(64376668К) < RR.image(64625832К)
И
sdb1(64376668 1K-блоков) < RR.image(64625832 1K-блоков) < sdb2(64742212 1K-блоков)
(Надеюсь, все было рассчитано правильно…)
Теперь я проверил блоки, которые зарезервированы для ROOT. Я нашел эту команду для выполнения:
root@sysresccd /root % dumpe2fs -h /dev/sdb1 2> /dev/null | awk -F ':' '{ if($1 == "Reserved block count") { rescnt=$2 } } { if($1 == "Block count") { blkcnt=$2 } } END { print "Reserved blocks: "(rescnt/blkcnt)*100"%" }'
Reserved blocks: 1.6%
root@sysresccd /root % dumpe2fs -h /dev/sdb2 2> /dev/null | awk -F ':' '{ if($1 == "Reserved block count") { rescnt=$2 } } { if($1 == "Block count") { blkcnt=$2 } } END { print "Reserved blocks: "(rescnt/blkcnt)*100"%" }'
Reserved blocks: 1.59999%
Таким образом, процент, зарезервированный для ROOT, также одинаков на обоих разделах, если это имеет значение.
Вот вывод для gdisk:
root@sysresccd /root % gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.1
Partition table scan:
MBR: MBR only
BSD: not present
APM: not present
GPT: not present
***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
Disk /dev/sdb: 312581808 sectors, 149.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): DCF8AFC4-11CA-46C5-AB7A-4818336EBCA3
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 312581774
Partitions will be aligned on 2048-sector boundaries
Total free space is 7789 sectors (3.8 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 131074047 62.5 GiB 8300 Linux filesystem
2 131074048 262889471 62.9 GiB 8300 Linux filesystem
3 302086144 312580095 5.0 GiB 0700 Microsoft basic data
5 262891520 293771263 14.7 GiB 8300 Linux filesystem
6 293773312 302086143 4.0 GiB 8200 Linux swap
Так каков же реальный размер sdb1?
sdb2Разве (N2) не больше, чем sdb1(N1)? Так ПОЧЕМУ же файл изображения РАСТЕТ БОЛЬШЕ, чем sdb2(N2)? Если я отключу зарезервированное для корня место на sdb2, тогда он туда поместится?
решение1
Каждая файловая система требует некоторого места для метаданных. Кроме того, extсемьярезервирует некоторое место для rootпользователяи по умолчанию это 5%.
Пример
В моем Kubuntu я создал (разреженный) файл размером 1 ГБ:
truncate -s 1G myfile
и сделал ext3файловую систему внутри него. Команда была простой
mkfs.ext3 myfile
Это мгновенно выделило около 49 МБ (~5% в данном случае) для myfile. Я мог видеть это, поскольку файл был разреженным и изначально сообщал об использовании 0 Б на моем реальном диске, затем он вырос. Я предполагаю, что именно там находятся метаданные.
Я смонтировал файловую систему; df -hсообщил о 976МиБ общего пространства, но доступно только 925МиБ. Это означает, что еще ~5% были мне недоступны.
Затем я заполнил это пространство (после cdточки монтирования)
dd if=/dev/urandom of=placeholder
Как обычный пользователь я мог взять только 925МиБ. Сообщаемое использование "диска" тогда было 100%. Однако, делая то же самое как root, я мог записать 976МиБ в файл. Когда файл превышал 925МиБ, использование оставалось на уровне 100%.
Заключение
Сравнение размеров разделов в данном случае неверно; как и сравнение размеров файловых систем. Вам следовало проверить доступное пространство на целевом дискефайловая система(например, с df) и сравните его с размером источникараздел.
РЕДАКТИРОВАТЬ:
Чтобы было понятно: ваши 66176851968 байт составляют около 61,63 ГиБ. Этонетбольше исходного раздела, который составляет 62,5 ГиБ. Исходныйразделне был полностью прочитан, когда цельфайловая системанаполнился.
Если вы не знакомы с различием ГБ/ГиБ, прочтитеman 7 units.
ПРАВКА 2
Теперь у нас есть все реальные числа. Давайте придерживаться единицы измерения 512B, это общий размер сектора.
- Твой
sdb1разделзанимает131074048-2048=131072000единицы на диске. Назовем этоP1. Это изgdiskвывода. - Твой
sdb2разделзанимает262889472-131074048=131815424единиц на диске. Пусть будетP2. Это тоже изgdiskвывода. - Твойфайловая системавнутри
sdb1можно хранить файлы до128753336единиц всего. Назовем это числоF1. Это изdfвывода. - Твойфайловая системавнутри
sdb2можно хранить до129484424единиц. Пусть будетF2. Это тоже изdfвывода.
Разницу между P1и F1, а также разницу между P2и F2, можно объяснить, если знать, что должно быть место для метаданных. Это упоминалось ранее в этом ответе.
Вы ddпытались скопировать всеsdb1 раздел, т.е. P1данных, в файл, который занимает место, предоставленноефайловая системавнутри sdb2, т.е. F2доступного пространства.
P1> F2– это окончательный ответ.Ваш файл изображения не увеличился больше, чем должен был. Мне кажется, вы ожидали, что его размер будет F1. Фактически, все изображение будет иметь размер P1единиц.
P2и F1не имеют значения в данном контексте.
решение2
После этого долгого обсуждения я понял, что вы имеете в виду.
Наконец-то мы добрались до сути. Ну, мой вопрос был немного неясным изначально, пока я его не отредактировал. Большое спасибо!
Я нашел эту команду для получения точного размера разделов в байтах:
root@sysresccd /root % parted /dev/sdb unit B p
Модель: ATA WDC WD1600AAJS-0 (scsi)
Диск /dev/sdb: 160041885696B
Размер сектора (логический/физический): 512Б/512Б
Таблица разделов: msdos
Флаги диска:
Номер Начало Конец Размер Тип Файловая система Флаги
1 1048576B 67109912575B 67108864000B первичная загрузка ext3
2 67109912576B 134599409663B 67489497088B основной ext3
4 134600457216B 154668105727B 20067648512B расширенный
5 134600458240B 150410887167B 15810428928B логический ext4
6 150411935744B 154668105727B 4256169984B логический linux-swap(v1)
3 154668105728B 160041009151B 5372903424B первичный жир 32 фунта
По сути, мне нужно сравнить реальный размер sdb1 (N1) в этом списке с доступным пространством на sdb2 (N2) в этом списке.
Но для этого мы используем команду POSIXLY_CORRECT=1 df на целевой файловой системе (sdb2), которая в данном случае составила: 129484424 512-байтовых блоков.
Если мы разделим 67108864000B из sdb1 на 512 b = 131072000 512b-блоков. Или мы можем умножить 129484424*512 = 66296025088 байт.
Итак, 66296025088 байт (доступное пространство на sdb2) < 67108864000 байт (сырой размер sdb1). Очевидно, что образ раздела sdb1 не может поместиться в доступное пространство на sdb2. И есть место, зарезервированное для ROOT на sdb2, которое также следует принять во внимание.
А что касается моего вопроса о файле образа, который больше раздела, то я в основном сравнил размер файловой системы sdb1 с образом DD вместо размера необработанного раздела, который должен быть полностью прочитан DD. Правильно? Я даже могу приблизительно подсчитать, сколько места мне нужно для завершения операции: 66 176 851 968 байт был размером незавершенного образа DD, поэтому я сравниваю его с размером необработанного раздела sdb1 66 176 851 968 = 661 76851 968 Б < 671 08864 000 Б = меньше на 932 012 032 байт = 888 МиБ
Но эй, что там на пустом разделе? Метаданные и место, зарезервированное для корня? Так много места???!!!!! Большое спасибо!!
Приятно все это знать!!