☰

대형 Ext4 드라이브에 대해 일반적으로 권장되는 예약된 블록(루트용) 수가 있습니까?

tag-icon • tag-icon root disk-usage ext4
대형 Ext4 드라이브에 대해 일반적으로 권장되는 예약된 블록(루트용) 수가 있습니까?

다음 질문을 통해:

대형 Ext4 드라이브에 대해 일반적으로 권장되는 예약된 블록(루트용) 수가 있습니까?

구체적으로 다음 사항을 언급하고 있습니다.

  • 요즘 (거의) 모든 사람이 상당히 큰 루트 드라이브(파티션)를 가지고 있다고 가정해 보겠습니다.

  • 1.8TiB 루트 파티션이 있는 2TB 드라이브를 생각해 보겠습니다. 이는 첫 번째 부팅 파티션을 제외한 전체 드라이브가 사용된다는 의미입니다.

  • 또한 나만이 이 컴퓨터에 액세스할 수 있고 하드웨어와 운영 체제에 직접 액세스할 수 있다고 가정해 보겠습니다.

  • 보완책으로 GRUB에 특정 문서를 설정했습니다. GRUB_CMDLINE_LINUX_DEFAULT="rootflags=data=journal"찾지 못했습니다.여기에 추가해 보세요..

이 모든 것을 실제 사례에 적용하기 위해 내 노트북에 있는 NVMe 드라이브는 다음과 같습니다.

# fdisk -l /dev/nvme0n1

Disk /dev/nvme0n1: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: Samsung SSD 970 EVO Plus 2TB            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 989573D5-37E7-437A-B680-9410F7234A94

Device          Start        End    Sectors  Size Type
/dev/nvme0n1p1   2048     194559     192512   94M EFI System
/dev/nvme0n1p2 194560 3907028991 3906834432  1.8T Linux filesystem

두 번째 파티션 /dev/nvme0n1p2은 Ext4 파일 시스템 유형입니다. 고려해야 할 전체 값 목록은 다음과 같습니다.

# tune2fs -l /dev/nvme0n1p2 
tune2fs 1.46.5 (30-Dec-2021)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          f1fc7345-be7a-4c6b-9559-fc6e2d445bfa
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              122093568
Block count:              488354304
Reserved block count:     20068825
Free blocks:              388970513
Free inodes:              121209636
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      817
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 Jun 16 11:26:24 2018
Last mount time:          Thu Oct 26 09:14:38 2023
Last write time:          Thu Oct 26 09:14:38 2023
Mount count:              102
Maximum mount count:      -1
Last checked:             Tue Sep 26 03:05:31 2023
Check interval:           0 (<none>)
Lifetime writes:          43 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
First orphan inode:       134214
Default directory hash:   half_md4
Directory Hash Seed:      48360d76-0cfb-4aed-892e-a8f3a30dd794
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x58d12a63

일부 예약된 루트 공간이 필요한지, 그렇다면 얼마나 필요한지 평가하고 싶습니다. 이 질문이 의견에 기반한 질문이 아니기를 바랍니다. 답변을 추가하기로 결정했다면 참고 자료를 추가해 주세요. 감사합니다.

답변1

따라서 중요한 이유가 전혀 없습니다.

가장 간단한 이유는 루트 실행 서비스가 로그 및/또는 데이터를 해당 볼륨에 저장하여 사용자가 드라이브에 데이터가 넘치더라도 계속 작동할 수 있도록 하기를 원한다는 것입니다. 분명히 이는 다음과 같은 경우에만 의미가 있습니다.

  1. 당신이 언급하는 볼륨은 실제로 루트로 실행되는 프로세스에서 사용됩니다.
  2. 또한 디스크를 파일로 채워 이러한 서비스의 작동을 거부할 수 없는 사용자가 사용하며,
  3. 권한이 없는 사용자가 사용자 데이터를 쓸 수 있는 것보다 서비스가 계속 실행되는 것이 더 중요합니다.

귀하의 시스템은 데스크탑 시스템인 것 같습니다. 따라서 필요한 것과 정반대는 아니더라도 적어도 3은 문제가 있다고 말하고 싶습니다.

그래서 저는 이것이 매우 약한 주장이라고 생각합니다. 특히 요즘 많은 서비스가 애초에 루트로 실행되지 않기 때문입니다.

그런 다음 (ext4의 "주" 개발자가 제시한) 또 다른 주장은 여유 공간이 많지 않으면 파일 시스템이 새 파일이나 증가하는 파일에 대한 연속 블록 영역을 찾는 것이 더 어렵다는 것입니다. 이는 소위분열, 이는 회전하는 디스크 저장소의 하드웨어 성능 문제(더 긴 검색 시간으로 인해)이며, 조각난 파일을 저장하고 읽는 더 복잡하고 리디렉션되는 방식으로 인해 여전히 오버헤드 문제입니다. 파일 시스템 드라이버는 스토리지 전체에 분산된 파일을 애플리케이션에 연속적으로 표시해야 하며, 이로 인해 프리페치 및 캐싱 기능이 SSD의 사소한 문제로 남아 있습니다. 또한 메타데이터의 크기도 늘어납니다. 나는 메타데이터에 대한 필요성이 증가하여 사용 가능한 공간이 줄어드는지, 아니면 조각난 파일에 액세스할 때 더 많은 조회가 필요한지 여부를 설명할 만큼 ext4의 내부 구조에 대해 잘 알지 못합니다.

https://listman.redhat.com/archives/ext3-users/2009-January/msg00026.html

예약된 블록 수를 0으로 설정하면 장시간 실행(많은 파일 생성 및 삭제)하고 파일 시스템이 거의 가득 차 있지 않는 한(예: 95%), 이 시점에서 조각화 문제가 발생하게 됩니다.

[…]

파일이 자주 변경되지 않는 장기 보관용 파일 시스템(예: 대용량 mp3 또는 비디오 저장소)을 사용하는 경우 이는 분명히 중요하지 않습니다.

따라서 실제로 사용 사례에 따라 다릅니다. 파일 시스템이 에 마운트되어 있는 것을 보면 /아마도 설치한 모든 소프트웨어가 있는 파일 시스템일 것입니다. 대규모 소프트웨어 업데이트는 많은 파일이 삭제되고 생성되는 시기입니다. 따라서 생성된 파일과 삭제된 파일의 크기가 균형을 이룰 때 평균적으로 충분히 인접한 스토리지 부분에서 자유롭게 선택할 수 있도록 충분한 공간을 예약하는 것이 합리적입니다.

그럼 그 금액은 얼마나 될까요? 말하기 어렵다. 그러나 대규모 업데이트 프로세스로 인해 20GB의 변경(새 파일 10GB, 이전 파일 10GB 삭제)이 발생할 수 있다고 가정하면 이는 실제로 합리적인 상한선처럼 보입니다. 그래서 공간 확보에 도움이 되는 것 같습니다.

파일 시스템 크기는 1.86TB입니다. 이는 NVMe가 아마도 소비자/프로슈머 1.92TB 장치임을 의미합니다. 현재 테라바이트당 실행 가격은 45~80유로입니다. 헤드룸을 "최적화"하는 것이 돈 측면에서 정신적 공간의 가치가 있는지 다시 확인하는 것이 좋습니다. 물론 78GB는 필요한 것보다 훨씬 많을 것입니다. 하지만 그 양이 6.60유로 미만인 경우 실제로 충분한지 충분히 고려하고 계십니까?

관련 정보