DD 출력 이미지 파일이 소스 파티션보다 크고 DD가 소스 파티션보다 크더라도 대상 파티션(이미지가 생성되는 곳)의 공간이 부족합니다.
동일한 디스크의 다른 파티션에 있는 파일에 파티션을 복사하려고 합니다. 대상 파티션은 입력 파티션보다 약간 큽니다. 둘 다 파티션입니다 ext3.
OpenSuse-Rescue LIVE CD에서 실행. Yast는 입력 파티션( sdb1)이 62.5GiB이고 출력 파티션이 sdb262.85GiB임을 보여줍니다.
Thunar는 입력 sdb1이 65.9GB이고 출력이 sdb266.2GB인 반면 출력 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
요청 시 추가 정보:
그리고 다시 : 소스 파티션 크기와 여기에서 생성된 sdb1DD 이미지 파일 의 차이를 확인했습니다 . RR.image해당 파일은 에 있습니다 sdb2.
여기에는 여전히 불분명한 점이 있습니다. DD를 루트로 실행 중이므로 예약된 공간에 쓸 수 있습니다. 맞습니까? 목표 sdb2는 62.85GiB이고 말씀하신 이미지의 총 바이트는 약 61.63GiB입니다. 다음은 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 이미지 파일 때문입니다. 지금은 그 파일이 유일한 파일이어야 합니다.이미지 파일 자체는 DD(런타임 기준) 및 Thunar 보고서 기준으로 66,176,851,968바이트입니다. 1024바이트로 나누면 64625832개의 K-블록이 맞나요? 따라서
df보고된 것 보다 여전히sdb2116380K 이상 작고sdb1(소스)보다 크지만 파티션을 최대화합니다sdb2.
문제는 그 공간을 차지하기 위해 거기에 무엇이 들어있느냐는 것입니다 sdb2.
그러나 가장 중요하고 흥미로운 점은 다음과 같습니다.
대상 파일이 해당 dd파일을 생성한 소스 파티션보다 큰 이유는 무엇입니까? 이는 나에게 의미가 있습니다. 다시 쓸 수 없습니다.
sdb1(64376668K) < RR.image(64625832K)
그리고
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)가 (N1)보다 크지 않나요 sdb1? 그러면 왜 이미지 파일이 sdb2(N2)보다 커지나요? 루트에 예약된 공간을 끄면 sdb2거기에 맞을까요?
답변1
모든 파일 시스템에는 메타데이터를 위한 약간의 공간이 필요합니다. 추가적으로 ext가족root사용자 를 위해 일부 공간을 예약합니다.기본적으로 5%입니다.
예
내 쿠분투에서는 1GiB의 (희소) 파일을 만들었습니다.
truncate -s 1G myfile
그리고 ext3그 안에 파일시스템을 만들었습니다. 명령은 간단했다
mkfs.ext3 myfile
이는 즉시 약 49MiB(이 경우 ~5%)를 myfile. 파일이 드물고 처음에 실제 디스크 사용량이 0B로 보고되었으므로 파일이 점점 커지는 것을 알 수 있었습니다. 나는 이것이 메타데이터가 존재하는 곳이라고 가정합니다.
파일 시스템을 마운트했습니다. df -h총 공간이 976MiB라고 보고되었지만 사용 가능한 공간은 925MiB만 있습니다. 이는 또 다른 ~5%가 나에게 제공되지 않았음을 의미합니다.
cd그런 다음 이 공간을 ( 마운트 지점 이후) 다음과 같이 채웠습니다.
dd if=/dev/urandom of=placeholder
일반 사용자로서 저는 925MiB만 사용할 수 있었습니다. 보고된 "디스크" 사용량은 100%였습니다. 그러나 와 동일한 작업을 수행하면 root파일에 976MiB를 쓸 수 있습니다. 파일이 925MiB 이상 증가하면 사용량은 100%로 유지되었습니다.
결론
이 경우 파티션 크기를 비교하는 것은 잘못된 것입니다. 파일 시스템의 크기를 비교하는 것도 마찬가지입니다. 대상에서 사용 가능한 공간을 확인했어야 합니다.파일 시스템(예: df)를 사용하여 소스의 크기와 비교합니다.분할.
편집하다:
명확하게 말하면 66176851968바이트는 약 61.63GiB입니다. 이것은~ 아니다62.5GiB인 소스 파티션보다 큽니다. 소스분할대상이 완전히 읽혀지지 않았습니다.파일 시스템가득 찼습니다.
GB/GiB 구분에 익숙하지 않은 경우 다음 내용을 읽어보세요.man 7 units.
편집 2
이제 우리는 실제 숫자를 모두 얻었습니다. 단위는 512B일반적인 섹터 크기입니다.
- 당신의
sdb1분할131074048-2048=131072000디스크의 단위를 차지합니다 . 이것을 이라고 부르자P1. 이것은gdisk출력에서 나온 것입니다. - 당신의
sdb2분할262889472-131074048=131815424디스크의 단위를 차지합니다 . 순리에 맡기다P2. 이것도gdisk출력에서 나온 것입니다. - 당신의파일 시스템내부에는 총 단위
sdb1까지 파일을 저장할 수 있습니다 .128753336이 번호로 전화하자F1. 이것은df출력에서 나온 것입니다. - 당신의파일 시스템내부에는 최대 1개
sdb2까지 보관할 수 있습니다129484424. 순리에 맡기다F2. 이것도df출력에서 나온 것입니다.
P1과 의 차이점 F1은 물론 이고 P2과 의 차이점은 F2메타데이터를 위한 공간이 있어야 한다는 것을 알고 있다면 설명할 수 있습니다. 이것은 이 답변의 앞부분에서 언급되었습니다.
dd전체를 복사하려고 하셨습니다 .sdb1 분할, 즉 P1데이터를 에서 제공하는 공간을 차지하는 파일로파일 시스템내부 sdb2, 즉 F2사용 가능한 공간.
P1> F2– 이것이 최종 답변입니다.이미지 파일이 예상보다 커지지 않았습니다. 제 생각엔 당신이 그 크기를 F1. 실제로 전체 이미지의 크기는 P1단위입니다.
P2F1이 맥락에서는 관련이 없습니다 .
답변2
오랜 토론 끝에 나는 당신이 무슨 뜻인지 깨달았습니다.
우리는 마침내 요점에 도달했습니다. 글쎄, 내 질문을 편집하기 전에는 처음에는 다소 모호했습니다. 정말 고마워!
정확한 파티션 크기를 바이트 단위로 얻으려면 다음 명령을 찾았습니다.
root@sysresccd /root % parted /dev/sdb 단위 B p
모델: ATA WDC WD1600AAJS-0(scsi)
디스크 /dev/sdb: 160041885696B
섹터 크기(논리적/물리적): 512B/512B
파티션 테이블: 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 lba
따라서 기본적으로 이 목록에 있는 sdb1(N1)의 실제 크기를 이 목록에 있는 sdb2(N2)의 사용 가능한 공간과 비교해야 합니다.
하지만 이를 위해 대상(sdb2) 파일 시스템에서 POSIXLY_CORRECT=1 df 명령을 사용합니다. 이 경우에는 129484424 512b-blocks입니다.
sdb1에서 67108864000B를 512로 나누면 b = 131072000 512b-blocks입니다. 또는 129484424*512 = 66296025088바이트를 곱할 수도 있습니다.
따라서 66296025088바이트(sdb2에서 사용 가능한 공간) < 67108864000바이트(sdb1의 원시 크기)입니다. 분명히 sdb1 파티션 이미지는 sdb2의 사용 가능한 공간에 맞지 않습니다. 그리고 sdb2에는 ROOT를 위해 예약된 공간도 고려해야 합니다.
그리고 파티션보다 큰 이미지 파일에 대한 질문에 대해 기본적으로 sdb1 파일 시스템 크기를 DD에서 전체로 읽어야 하는 원시 파티션 크기 대신 DD 이미지와 비교했습니다. 옳은? 작업을 완료하는 데 필요한 공간의 양을 대략적으로 추정할 수도 있습니다. 66,176,851,968바이트는 불완전한 DD 이미지의 크기이므로 이를 원시 sdb1 파티션의 크기와 비교합니다. 66,176,851,968 = 66176851968 B < 67108864000 B = 932012032만큼 작음 바이트 = 888 MiB
그런데 빈 파티션에는 무엇이 들어있나요? 루트용으로 예약된 메타데이터 및 공간이 있습니까? 공간이 너무 많아요 ???!!!!! 매우 감사합니다!!
이것저것 알아가서 좋네요!!