☰

ext4: 파일 시스템 공간을 어떻게 차지합니까?

tag-icon • tag-icon filesystems disk-usage ext4
ext4: 파일 시스템 공간을 어떻게 차지합니까?

최근에 1.5TB 드라이브를 포맷했고 ntfs를 ext4로 교체할 계획이었습니다.

그러다가 내가 저장한 파일이 새 파티션에 맞지 않는다는 것을 알았습니다.

df:

ext4 (ext3 & ext2 show the same behavior)
Filesystem      1K-blocks   Used  Available Use% Mounted on
/dev/sdb1      1442146364   71160 1442075204    1% /media/Seagate

ntfs (similar to all other options that gparted offers):
/dev/sdb1      1465137148  110700 1465026448    1% /media/Seagate

1K 블록의 차이는 사용 가능한 공간이 22GiB만큼 훨씬 적다는 것을 의미합니다.

나는 이미 처형했다

tune2fs -O \^has_journal
tune2fs -r 0
tune2fs -m 0

당연히 존재하지 않는 블록에는 영향을 미치지 않으므로 아무런 효과가 없습니다.

그럼에도 불구하고 fdisk는 ext4 파티션이 전체 디스크를 포함한다고 보고합니다.

fdisk -l /dev/sdb:

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.

Disk /dev/sdb: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  2930277167  1465138583+  ee  GPT

예를 들어 resize2fs는 "Nothing to do!"라고 보고합니다.

dumpe2fs -h /dev/sdb1:
dumpe2fs 1.41.14 (22-Dec-2010)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          d6fc8971-89bd-4c03-a7cd-abdb945d2173
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              91578368
Block count:              366284288
Reserved block count:     0
Free blocks:              360518801
Free inodes:              91578357
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      936
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Sat May 21 17:12:04 2011
Last mount time:          Sat May 21 17:15:30 2011
Last write time:          Sat May 21 17:24:32 2011
Mount count:              1
Maximum mount count:      32
Last checked:             Sat May 21 17:12:04 2011
Check interval:           15552000 (6 months)
Next check after:         Thu Nov 17 16:12:04 2011
Lifetime writes:          1372 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     28
Desired extra isize:      28
Default directory hash:   half_md4
Directory Hash Seed:      c334e6ef-b060-45d2-b65d-4ac94167cb09
Journal backup:           inode blocks

사라진 공간은 무엇에 사용되나요?

답변1

보자. 장치 크기는 1,465,138,583½ kB = 1,500,301,909,504 B입니다. 파일 시스템은 각각 4096바이트, 즉 1,500,300,443,648바이트의 366,284,288개 블록으로 구성됩니다. 나머지 1,465,856B(1.4MB)가 슈퍼블록의 (추가) 복사본에 사용되는지 궁금합니다. 부트로더 시작 부분에 몇 kB의 공간이 있다는 것을 알고 있습니다. ).

파일 시스템에는 91,578,368개의 inode가 포함되어 있으며 각 inode는 256바이트로 23,444,062,208바이트(약 22GB, 힌트, 힌트)를 차지합니다. 그러면 파일 내용은 1,442,146,364kB = 1,476,757,876,736B입니다. 이는 23,444,062,208 B + 1,476,757,876,736 B = 1,500,201,938,944 B와 같습니다. 남은 크기는 98,504,704 B = 24,029 블록으로, 이는 로그 크기의 올바른 범위 내에 있습니다.

보시다시피 모든 것이 고려되었습니다. (거의 모든 것이 있지만 기가바이트가 아니라 메가바이트를 말하는 것입니다.)

답변2

첫째, 사용 가능한 공간의 차이는 "낭비된" 공간이 있다는 의미가 아니라 공간이 "낭비되고 있는" 것을 의미합니다. 파일 시스템 작동에 필수적이므로 낭비되지 않습니다. 파일 시스템과 각 구현의 세부 사항(예: 각 드라이버가 VFS 계층에 여유 공간을 보고하는 방법) Ext4와 NTFS 간의 모든 설계 및 구조적 차이점을 지정하는 매우 큰 "그러나" 없이는 이러한 방식으로 비교해서는 안됩니다.

파티션을 가지고 있는 모든 데이터를 배치할 수 있는 거대한 공간으로 생각하십시오. 크기가 파티션과 동일한 데이터 조각이 하나만 있는 경우 파티션 시작 부분부터 데이터 쓰기를 시작하여 완료할 수 있습니다. 하지만 당신은 그렇지 않습니다. 대신 수천 개의 작은 파일이 서로 다른 방식으로 그룹화되고 각각이 다른 많은 작은 데이터(이름, 날짜/시간, 권한) 등과 연결되어 있을 수 있습니다. 넓은 공간을 정리해야 합니다. 이 모든 데이터에 빠르고 효율적으로 액세스할 수 있도록 파티션을 나누세요. 추가적으로, 새로운 데이터를 효율적으로 쓰는 것과 오래된 데이터를 폐기하는 것에도 신경을 써야 합니다. 당신은해야합니다데이터 구조.

그리고 가지고많은 데이터 구조. 그 중 일부는 매우 멍청하고, 다른 일부는 느린 쓰기 속도에서 더 빠르게 데이터를 검색할 수 있게 하고, 다른 일부는 더 빠른 읽기 속도로 쓸 수 있게 하며, 일부는 여전히 읽기 및 쓰기에 매우 능숙하지만 다음과 같은 경우 긴 시간 일시 중지 및 유휴 오버헤드가 필요할 수 있습니다. 데이터 재배열 등

당신은 확실히 다음과 같은 시스템을 원합니다.

  1. 정보 작성 속도는 매우 빠릅니다.
  2. 여기에서 정보를 검색하는 속도는 매우 빠릅니다.
  3. 저장된 정보를 정리하고 관리하는 데 능숙합니다.
  4. 파일 시스템이 저장된 공간(파티션)을 최대한 활용하세요.
  5. 하드웨어 문제에 강하므로 시스템 일부에 오류가 발생하더라도 대부분 또는 전체 정보를 복구할 수 있습니다.
  6. 소프트웨어 문제로부터 보호하므로 앱의 버그나 설치된 악성 앱으로 인해 데이터가 영구적으로 손상되지 않습니다.
  7. 사람의 실수를 견딜 수 있도록 제작되었으므로 실수로 시스템에 삭제해서는 안 되는 항목(일명 휴지통/휴지통)을 삭제하도록 명령해도 용서해 줍니다.

고성능 파일 시스템을 사용하면 일부 공간을 희생하더라도 매우 빠른 읽기 및 쓰기가 가능합니다. 파일 시스템에서 사용되는 가장 빠른 데이터 구조 중 일부는 다음과 같습니다.해시 테이블그리고B-트리, 매우 복잡하며 매우 빠른 액세스를 허용하기 위해 실제로 사용되는 것보다 더 많은 공간을 예약합니다.

Ext4에는 다른 중요한 속성이 있습니다. 파일 시스템에는 단일 실패 지점이 없습니다. 파티션 전체에 중요한 데이터의 복사본이 많이 분산되어 있으며 일부 다른 파일 시스템(NTFS의 경우에도 동일하다고 말할 수 없음)이 올바른 위치에서 실패하면 모든 데이터를 읽을 수 없게 만들 수 있습니다. 또한 Ext4는 파일 시스템 생성 단계에서 데이터를 위한 많은 공간을 예약하는 반면 NTFS는 데이터와 함께 성장합니다.

답변3

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! 
The util fdisk doesn't support GPT. Use GNU Parted.

이 메시지는 디스크가 GPT 스타일 파티셔닝을 사용하며 이 fdisk도구는 레거시 MBR 스타일만 이해한다는 것을 나타냅니다.

GPT 파티션으로 분할된 디스크를 GPT를 인식하지 않는 이전 시스템에 연결할 때 실수로 다시 포맷되는 것을 방지하기 위해 GPT 파티션 구성표에는 "보호 MBR"이 포함되어 있습니다. 기본적으로 "이 디스크는 사용자가 완전히 사용했습니다"라고 알려주는 완전히 가짜 파티션 테이블입니다. 사용할 파티션 유형"입니다. MBR 파티션만 이해하는 운영 체제나 도구에 대해서는 아무것도 모릅니다.

파티션 테이블을 정확하게 표시하려면 /dev/sdb다음을 사용하십시오.

parted /dev/sdb print

관련 정보