SSD에 가장 적합한 Linux 파일 시스템

119

위키에서 :

필수 TRIM 기능은 2.6.33 커널 (2010 년 초부터 사용 가능)부터 Linux OS에서 지원됩니다. 그러나 다양한 파일 시스템 간의 지원은 여전히 ​​일관되지 않거나 존재하지 않습니다. 설치 소프트웨어는 적절한 파티션 정렬을 수행하지 않습니다.

그렇다면 어떤 파일 시스템이 SSD에 가장 적합하며 설치 중에 TRIM + 파티션 정렬을 지원하며 Ubuntu에서 사용할 수 있습니까?

linux  filesystems  ssd 
— hbt
소스

답변:

89

파일 시스템 EXT4 + TRIM :

  • TRIM이있는 EXT4는 쓰기 / 쓰기주기가 제한되어 SSD 드라이브에 대한 불필요한 쓰기주기를 줄임으로써 성능을 향상시킵니다.
  • Ubuntu 및 기타 Linux 버전은 TRIM을 사용하여 EXT 4를 즉시 지원합니다.

스왑 파티션 :

  • 쓰기주기를 줄이려면 SSD에 SWAP 공간이 없는지 확인하십시오.
  • 기계식 드라이브가있는 경우 기계식 드라이브에 SWAP 공간을 작성하고 SSD에 공간을 두지 마십시오.

파티션 정렬 :

  • 파티션은 파일 시스템의 블록 크기가 SSD의 블록 크기와 정렬되도록 깨끗한 ​​1MB 경계에서 시작해야합니다.

따라서 EXT4 + TRIM 을 기계식 하드 드라이브에서 SWAP와 함께 사용 하거나 SSD에서 SWAP를 사용하지 마십시오 .

위의 내용은 소스 : SSD 성능을 최대화하는 방법을 참조하여 구현할 수 있습니다 .

— 별명
소스
GPT는 사용 현대 방법 gdisk및 grub 2.0.x, (나는 누군가가 대답 아래에 언급 추측)와 MBR 이전을 사용하여 기존의 방법 grub 0.9.7과 fdisk.. 당신이 여기에서 자세한 내용을 찾을 수 있습니다 wiki.archlinux.org/index.php/Solid_State_Drives를
— aliasgar
7
또한 지정할 nodiratime때 지정할 필요가 없습니다 noatime. 동의, 그것은 동료 대단하다에 시원하고 고급 보이지만 noatimeinodes에서 시간을 비활성화하고 디렉토리도 inode이므로 "손을 씻고 엄지 손가락을 씻으십시오" 라고 말하는 것과 같습니다 . :)
— Redsandro 2016 년
경험상 스케줄러 ( "noop")가 마감 시간보다 빨리 작동하지 않는다고 말할 수 있습니다.
— drumfire
5
아니요, " 기본 블록 장치가 TRIM을 지원할 때 Linux 스왑 파티션 은 기본적으로 TRIM 작업을 수행합니다.이 기능을 끄거나 한 번 또는 연속적인 TRIM 작업 중에서 선택할 수 있습니다." 따라서 빠른 액세스 시간을 활용하기 위해 스왑 파티션을 SSD에 배치해야합니다. 각 페이지 스왑이 발생할 때마다 많은 시간이 소요됩니다
— phuclv
2
@aliasgar F2FS는 ext4에 비해 좋은 선택입니까?
— SebMa
67

짧은 답변

  • 선택 에서 ext4를 하고, 중 으로 마운트 discard에 대한 옵션 TRIM을 지원 또는 FITRIM을 사용 (아래 참조). noatime"SSD 마모"가 우려되는 경우에도이 옵션을 사용하십시오 .

  • 프로세스간에 공정성을 제공하고 자동 SSD를 지원하므로 다중 애플리케이션 서버 에서 CFQ (기본 I / O 스케줄러) 를 변경하지 마십시오 . 그러나 데스크톱 에서 데드 라인 을 사용 하면로드시 응답 성이 향상됩니다.

  • 적절한 데이터 정렬을 쉽게 보장하려면 각 파티션의 시작 섹터는 2048의 배수 (= 1MiB) 여야합니다 . fdisk -cu /dev/sdX그것들을 만드는 데 사용할 수 있습니다 . 최근 배포판에서는 자동으로이를 처리합니다.

  • SSD에서 스왑을 사용하기 전에 두 번 생각하십시오. 아마도 HDD의 스왑에 비해 훨씬 빠를 것이지만 디스크를 더 빨리 마모시킬 것입니다 (관련되지 않을 수도 있습니다, 아래 참조).

긴 대답

  • 파일 시스템 :

Ext4 는 가장 일반적인 Linux 파일 시스템입니다. SSD와 함께 우수한 성능을 제공하고 TRIM (및 FITRIM) 기능을 지원하여 시간이 지남에 따라 우수한 SSD 성능을 유지합니다 (이렇게하면 사용하지 않은 메모리 블록이 지워져 나중에 빠르게 쓰기 액세스 할 수 있음). NILFS 는 특히 플래시 메모리 드라이브 용으로 설계되었지만 벤치 마크에서 실제로 ext4 보다 성능이 우수 하지는 않습니다 . BTRFS는 아직 실험으로 간주됩니다 (정말 더 잘 수행하지 않습니다 중 하나 ).

  • SSD 성능 및 트림 :

트림 기능은 파일 시스템에서 더 이상 사용되지 않는 SSD 블록을 지 웁니다. 이렇게하면 장기적인 쓰기 성능이 최적화되며 디자인으로 인해 SSD에서 권장됩니다. 파일 시스템이 드라이브에 해당 블록에 대해 알려줄 수 있어야합니다. ext4 의 discard마운트 옵션은 파일 시스템 블록이 해제 될 때 이러한 TRIM 명령 을 발행 합니다. 이것은 온라인 폐기 입니다.

그러나이 동작은 약간의 성능 오버 헤드를 의미합니다. Linux 2.6.37부터는 FITRIM을 사용하여 (예 : crontab에서) 일괄 처리discard 를 사용하지 않고 선택적으로 일괄 삭제 를 수행 할 수 있습니다 . 이 fstrim유틸리티는이 -E discard옵션 (온라인)과 옵션을 수행 fsck.ext4합니다. 그러나이 도구의 "최근"버전이 필요합니다.

  • SSD 마모 :

SSD는 이와 관련하여 수명이 제한되어 있으므로 드라이브 쓰기를 제한 할 수 있습니다. 그러나 너무 걱정하지 마십시오 . 오늘날 최악의 128GB SSD는 5 년 이상 하루 에 최소 20GB의 쓰기 데이터 (셀당 1000 쓰기주기)를 지원할 수 있습니다 . 더 나은 것 (그리고 더 큰 것)은 훨씬 더 오래 지속될 수 있습니다.

SSD에서 스왑 을 사용하려는 경우 커널은 비 회전 디스크를 발견하고 스왑 사용량 (커널 레벨웨어 레벨링) 을 무작위로 지정 합니다. 그러면 SS스왑이 활성화되면 커널 메시지에 (Solid State)가 표시됩니다.

/ dev / sda1에 2097148k 스왑 추가 우선 순위 : -1 범위 : 1 전체 : 2097148k SS

  • I / O 스케줄러 :

또한 나는 대부분의 aliasgar 의 답변에 동의하지만 (대부분의 경우이 웹 사이트 에서 불법적으로 복사 되었더라도 ) 스케줄러 부분 에 부분적으로 동의하지 않아야합니다 . 기본적으로 최종 기한 스케줄러 는 엘리베이터 알고리즘을 구현할 때 회전 디스크에 최적화되어 있습니다. 자,이 부분을 명확히하자.

스케줄러에 대한 긴 답변

커널 2.6.29부터 SSD 디스크가 자동으로 감지되며 다음을 통해이를 확인할 수 있습니다. 

cat /sys/block/sda/queue/rotational

당신은 가야 1하드 디스크과 0SSD를 위해.

이제 CFQ 스케줄러는이 정보를 기반으로 동작을 조정할 수 있습니다. 리눅스 3.1부터 커널 문서 cfq-iosched.txt파일 은 다음과 같이 말합니다 :

CFQ에는 SSD에 대한 일부 최적화 기능이 있으며 높은 큐 깊이 (한 번에 여러 요청을 한 번에 여러 요청)를 지원할 수있는 비 회전 미디어를 감지하면 [...].

또한 최종 기한 스케줄러는 섹터 번호를 기준으로 회전 디스크에서 정렬되지 않은 헤드 이동을 제한하려고합니다. 커널 doc 인용 deadline-iosched.txt, fifo_batch 옵션 설명 :

요청은 증가하는 섹터 순서로 서비스되는 특정 데이터 방향 (읽기 또는 쓰기)의``배치 ''로 그룹화됩니다.

그러나 SSD를 사용할 때이 매개 변수를 1로 조정하면 흥미로울 수 있습니다.

이 매개 변수는 요청 당 대기 시간과 총 처리량 간의 균형을 조정합니다. 낮은 대기 시간이 주요 관심사 인 경우 더 작은 것이 좋습니다 (1 값이 선착순 동작을 생성 함). fifo_batch를 늘리면 일반적으로 대기 시간 변동 비용으로 처리량이 향상됩니다.

일부 벤치 마크 에서는 서로 다른 스케줄러간에 성능 차이가 거의 없음을 제안 합니다 . 그렇다면 공정성을 권장하지 않는 이유는 무엇입니까? CFQ가 벤치에서 거의 나쁘지 않을 때 . 그러나 데스크톱 설정에서는 일반적으로 디자인 때문에 (아마도 처리량 비용은 낮음)로드시 데드 라인 을 사용하여 응답 성이 향상됩니다.

즉, 더 나은 벤치 마크는 마감일을로 사용해보십시오 fifo_batch=1.

SSD에서 기본적으로 데드 라인을 사용하려면 /etc/udev.d/99-ssd.rules다음과 같이 파일을 만들 수 있습니다 .

# all non-rotational block devices use 'deadline' scheduler
# mostly useful for SSDs on desktops systems
SUBSYSTEM=="block", ATTR{queue/rotational}=="0", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/scheduler}="deadline"
— 토토
소스
최근 배포에서 분할 정렬이 자동으로 처리된다는 것은 무엇을 의미합니까? 예를 들어 우분투 설치 중에 수동 파티션을 사용하거나 gparted로 파티션을 할 때에도 적용됩니까?
— jarno
2
fdisk에서 그래픽에 이르기까지 가장 최근의 배포판에서 @jarno (파티션 도구)는 장치 시작부터 1Mb의 배수로 파티션 정렬을 만들도록 자동 기본 설정되는 경향이 있습니다. 이것은 자연적으로 2 ^ n 인 512byte, 4k, 8k 및 반 bazillion 다른 블록 / 클러스터 크기와 선제 적으로 정렬됩니다. 상당한 노력을 기울이지 않으면 파티션을 잘못 정렬하는 것이 거의 불가능합니다.
— killermist
13

archlinux 기사 Solid State Drives 는 파일 시스템 선택 섹션에서 말합니다 :

Ext2 / 3 / 4, Btrfs 등을 포함한 파일 시스템에는 많은 옵션이 있습니다.

Btrfs
Btrfs 지원은 Linux 커널의 메인 라인 2.6.29 릴리스에 포함되었습니다. 일부는 ext4에 대한이 후속 모델의 얼리 어답터가 있지만 프로덕션 용도로는 충분히 성숙하지 않은 것으로 생각합니다. 자세한 정보 는 Btrfs 기사 를 읽는 것이 좋습니다 .

Ext4
Ext4는 SSD를 지원하는 다른 파일 시스템입니다. 2.6.28 이후 안정적으로 간주되며 매일 사용하기에 충분히 성숙합니다. Btrfs와 달리 ext4는 디스크 특성을 자동으로 감지하지 않습니다. 사용자는 fstab의 폐기 마운트 옵션 (또는 tune2fs -o waste / dev / sdaX)을 사용하여 TRIM 명령 지원을 명시 적으로 활성화해야합니다.

Btrfs와 Ext4는 모두 SSD를 효율적으로 사용하기위한 두 가지 주요 요구 사항을 충족합니다.

  • 파일 시스템은 기본 SSD에 ATA_TRIM 명령을 실행할 수 있어야합니다.
  • 파일 시스템은 디스크에 불필요한 쓰기를 수행해서는 안됩니다

성능을 위해 두 가지 다른 요구 사항이 있습니다.

  • 파티션은 SSD의 블록 크기에 맞춰야합니다
  • 각 Ext4 형식 파티션에 대해 TRIM을 명시 적으로 활성화해야합니다.

첫 번째는 오늘날 대부분의 Linux 설치 프로그램에서 자동으로 수행됩니다. fdisk는 "-cu"플래그로 시작하면 1024KB 경계에 파티션을 작성합니다.

두 번째는 Btrfs의 경우 자동이지만 Ext4의 경우 "/ etc / fstab"파일의 각 Ext4 파티션에 대한 마운트 옵션 목록에 "discard"를 추가하여 수동으로 수행됩니다. 자세한 내용은이 하우투를 참조하십시오 .

내 의견으로는 Ext4에 fstab을 거의 사용하지 않아도이 성숙하고 우수한 파일 시스템을 사용하지 않아도됩니다.

— 해리
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.