ext4 : 파일 시스템 공간을 설명하는 방법? 전체 디스크를 커버한다고보고합니다. fdisk -l /dev/sdb: WARNING: GPT

최근에 ntfs를 ext4로 바꾸려는 의도로 1.5TB 드라이브를 포맷했습니다.

그런 다음 저장 한 파일이 새 파티션에 맞지 않는 것으로 나타났습니다.

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,465,138,583½ kB = 1,500,301,909,504 B입니다. 파일 시스템은 각각 4096B의 366,284,288 블록으로 구성되며 1,500,300,443,648B입니다. 남은 1,465,856 B (1.4 MB)가 (슈퍼 블록의 추가 사본)에 사용되는 것을 모릅니다 부트 로더의 시작 부분에 약간의 kB 공간이 있다는 것을 알고 있습니다.)

파일 시스템에는 각각 256 바이트의 91,578,368 inode가 포함되어 있으며 23,444,062,208B (약 22GB, 힌트, 힌트)를 차지합니다. 그런 다음 파일 내용에 대해 1,442,146,364 kB = 1,476,757,876,736 B가 있습니다. 이것은 23,444,062,208 B + 1,476,757,876,736 B = 1,500,201,938,944 B를 차지합니다. 나머지 크기는 98,504,704 B = 24,029 블록이며 저널 크기에 적합한 범위입니다.

보시다시피 모든 것이 설명됩니다. (좋아, 거의 모든 것이지만 우리는 기가 바이트가 아닌 메가 바이트를 이야기하고 있습니다.)


답변

우선,보고있는 사용 가능한 공간의 차이가 공간이 낭비되었다는 의미는 아닙니다. 파일 시스템이 작동하기 위해서는 근본적으로 중요하기 때문에 낭비되지 않습니다. 파일 시스템 간의 모든 디자인과 구조적 차이와 각 구현의 특성 (예 : 각 드라이버가 여유 공간을 VFS 계층에보고하는 방식)을 지정하는 매우 큰 “그러나”없이 Ext4와 NTFS를 이러한 방식으로 비교해서는 안됩니다.

파티션을 모든 데이터를 넣을 수있는 거대한 공간이라고 상상해보십시오. 파티션과 동일한 크기의 데이터가 하나만 있다면 파티션의 시작 부분부터 시작하여 멋지게 만들 수 있습니다. 그러나 당신은하지 않습니다. 대신 수천 개의 작은 파일이있을 수 있으며 이러한 모든 파일은 서로 다른 방식으로 그룹화되어 있으며 각 파일은 다른 많은 작은 데이터 조각 (이름, 날짜 / 시간 및 권한) 등과 관련되어 있습니다. 이러한 모든 데이터에 빠르고 효율적으로 도달 할 수 있도록 파티션을 만듭니다. 또한 새로운 데이터를 작성하고 오래된 데이터를 효율적으로 버리는 방법에 대해 염려해야합니다. 데이터 구조 가 필요 합니다 .

그리고 많은 데이터 구조가 있습니다 있습니다. 그중 일부는 매우 멍청하고 다른 일부는 더 느린 쓰기 비용으로 더 빨리 데이터를 검색 할 수 있으며, 다른 읽기는 읽기 비용으로 더 빨리 쓰기를 허용합니다. 데이터 등을 재정렬하는 동안 유휴 오버 헤드

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

  1. 정보를 작성하는 것이 매우 빠릅니다.
  2. 정보를 검색하는 것이 매우 빠릅니다.
  3. 정보를 저장하고 관리하는 데 능숙합니다.
  4. 파일 시스템이 저장된 공간 (파티션)을 잘 활용합니다.
  5. 하드웨어 문제에 대해 탄력적이므로 부분적인 시스템 오류에 대한 정보의 대부분 또는 전부를 다시 얻을 수 있습니다.
  6. 소프트웨어 문제에 대해 탄력적이므로 응용 프로그램의 버그 또는 악의적 인 응용 프로그램이 설치 되어도 데이터가 영구적으로 손상되지 않습니다.
  7. 인적 오류에 대해 탄력적이므로 실수로 시스템에 원하지 않는 항목 (휴지통 / 휴지통)을 삭제하도록 주문할 때 용서할 수 있습니다.

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

Ext4에는 다른 중요한 속성이 있습니다. 파일 시스템에는 단일 실패 지점이 없습니다. 파티션을 통해 중요한 데이터의 사본이 많이 있지만, 다른 파일 시스템 (NTFS의 경우 말할 수없는)은 장애가 적절한 지점에서 발생하면 모든 데이터를 읽을 수 없게 만들 수 있습니다. 또한 Ext4는 파일 시스템 생성 단계에서 데이터를위한 충분한 공간을 확보하고 NTFS는 데이터와 함께 커집니다.


답변

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


답변