외장 하드 드라이브의 XFS 또는 ext4


8

파일을 백업하려는 외장 하드 드라이브가 있습니다.

XFS와 ext4 사이의 어느 파일 시스템이 하드 드라이브에 데이터를 쓰는 것이 가장 빠릅니까?

답변:


8

내 실제적인 대답을 반지에 던져 보자. ext4로 가라. 극단적 인 경우를 제외하고는 XFS와 비교하여 읽기 / 쓰기 차이가 없습니다 (예 : 수십만 개의 작은 파일을 대량으로 삭제).

AskUbuntu와 같은 곳에서 ext4에 대한 더 많은 커뮤니티 지원을 찾을 수 있습니다.

XFS의 주목할만한 단점은 XFS 파티션 크기를 줄이려면 백업, 재 파티션 / 재 포맷, 복원을 수행해야한다는 것입니다 (파티션 크기 감소).


XFS에 데이터 손상 감지 기능이 있습니까?
endolith

1
@endolith no XFS는 데이터 손상 감지 기능이 없습니다. 메타 데이터 손상 감지를 형식화 (또는 활성화) 할 수 있습니다 ( CRC를 통해 man7.org/linux/man-pages/man8/mkfs.xfs.8.html 의 시조 플래그 참조 ). 이것은 탐지 전용이지만 종종 메타 데이터를 복구 / 재 구축 할 수 있습니다. 이 기능은 XFS가 자동 손상을 감지하도록 도와줍니다.
Huygens

7

ext4

이 파일 시스템은 2012 년의 권장 사항이며 2017 년의 권장 FS입니다.이 파일 시스템은 암호화 지원 (2017 년 기준 최신 커널 필요)으로 매우 성숙하며 외장 하드 드라이브 (및 외장 SSD)의 대부분의 작업 부하에 대해 충분히 빠릅니다. ) 또한 데이터 안전과 관련하여 매우 안전한 선택입니다. 특히 외부 하드 디스크가있는 경우 중요한 요소이므로 내부 하드 디스크만큼 보호되지 않습니다.

예를 들어 랩톱에서는 전기가 연결되어 있어도 배터리가 남아 있으므로 내부 드라이브는 다소 안전합니다. 그러나 외장 플러그가 연결된 하드 디스크는 연결이 끊어 질 수 있습니다.

XFS

많은 엔터프라이즈 워크로드 및 일부 데스크탑 워크로드에 대해 우수한 성능을 제공합니다. 아마도 이러한 엣지 케이스는 외장 USB 하드 드라이브에 표시되지 않으며 USB3.1 인터페이스의 외장 SSD로 표시 될 수 있습니다. XFS에서 일부 파일이 0으로 잘리는 것보다 연결이 끊어 지거나 전원이 끊기는 것보다 더 높은 위험이 있었지만, 수년 동안 이것은 문제가되지 않았습니다. XFS는 이제 전력 손실시에도 강력하고 빠른 파일 시스템입니다.

예를 들어 LUKS를 사용하는 경우 XFS로 암호화를 구현할 수 있습니다. 그러나 XFS 내에서 암호화에 대한 기본 지원을 알지 못합니다.

BTRFS

2012 년에 나는 "1 년 또는 2 년 안에 파일 시스템이 데이터 및 저널에 대한 체크섬을 지원하기 때문에 그 파일 시스템을 추천 할 것"이라고 말했습니다. 2017 년에 RAID 5-6 지원을 사용하지 않으면이 파일 시스템이 매우 강력하다고 말할 수 있습니다 (최신 커널이 필요하므로 Ubuntu 18.04 LTS를 기다리는 것이 좋습니다). 내부 하드 디스크보다 노출 된 외부 하드 디스크에서 BTRFS는 기본 데이터 및 메타 데이터 체크섬이있는 매우 강력한 솔루션입니다. 그러나 외장 하드 드라이브가 하나 뿐인 경우 손상된 데이터 만 감지 할 수 있지만 드라이브에 각 데이터 또는 메타 데이터의 사본 2 개를 저장하도록 설정하지 않으면 복구 할 수 없습니다. 디스크 손실의 경우 물론 모든 것을 잃어 버리므로 RAID1이 아닙니다. 그러나 손상된 섹터가 있으면 사본이 있으면 BTRFS가 복구 할 수 있습니다. BTRFS는 스냅 샷을 지원합니다.

디스크 사용 및 여유 공간 문제 (특히 압축 옵션을 사용하는 경우)를 올바르게 이해하는 것과 같은 몇 가지 특징이 있기 때문에 권장 파일 시스템이 아닙니다. BTRFS를 사용할 때 약간의 밸런싱 등이 필요한 장치에 남은 공간이 없어서 몇 번 오류가 발생했습니다. 따라서 초보자 사용자는 아직 사용할 수 없습니다.


실제로 후속 조치를 취하고 업데이트 한 것이 좋습니다.
legends2k

귀하의 의견에 감사드립니다 @ legends2k :-) 대단히 감사합니다
Huygens

5

대답은 정확한 요구 사항에 따라 다릅니다.

ext4는 Ubuntu, Fedora 및 openSUSE를 포함하여 널리 사용되는 Linux 배포판의 기본 파일 시스템이되었습니다. ext4는 이전 버전에 비해 몇 가지 향상된 기능을 제공하며, 그중에는 최대 16 개의 테비 바이트 (1 개의 테비 바이트는 1,024 기가비트, 1 기가 바이트는 1.074 기가 바이트) 및 최대 볼륨 크기는 1 엑비 바이트까지 지원됩니다. ext3 및 ext2와 역 호환되므로 ext3 및 ext2를 ext4로 마운트 할 수 있습니다. 새로운 블록 할당 알고리즘과 같은 ext4 및 ext2와 함께 ext4의 특정 새로운 기능을 사용할 수 있기 때문에 성능이 약간 향상됩니다.

XFS는 원래 Silicon Graphics, Inc.에서 설계 한 확장 성이 뛰어난 고성능 파일 시스템입니다.이 파일 시스템은 매우 큰 파일 시스템을 지원하도록 만들어졌습니다. XFS는 8 엑비 바이트에서 1을 뺀 1 (즉, 263-1 바이트)의 최대 파일 시스템 크기를 지원하지만 호스트 운영 체제에 의해 부과 된 블록 제한이 적용됩니다. 32 비트 Linux 시스템은 파일 및 파일 시스템 크기를 16TB로 제한합니다.

이 주제에 대한 많은 정보가 있지만 여기서 시작 하고 더 자세히 살펴보고 싶다면 탐구하려고합니다.

이게 도움이 되길 바란다.

출처 :

-http : //techie-buzz.com/foss/google-implements-ext4.html

-http : //docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.0_Release_Notes/filesystems.html


RHEL 7부터는 XFS가 기본 파일 시스템입니다 -access.redhat.com/articles/796293
Bert

1

나는이 파일 시스템의 많은 벤치 마크를 보았는데, EXT4가 더 낫다고 생각하지만 XFS와의 차이점은 최소한이라고 생각합니다 ...

읽기 / 쓰기 벤치 마크에는 많은 차이가 없으며 EXT4를 사용하며 환상적입니다.


1

작업량이 심각한 경우 ext4를 사용하지 않는 것이 좋습니다.

우리는 소프트웨어의 동시 빌드를 실행하는 두 개의 빌드 서버를 가지고 있으며 둘 이상의 동시 빌드를 수행하면 중단 된 작업이 발생하여 빌드가 강제 종료됩니다. 한 번에 하나의 빌드 만 수행하면 정상적으로 완료됩니다. 그러나 이것은 이론적으로 8 개의 동시 빌드 (또는 1 -j8 빌드)를 수행 할 수있는 멀티 CPU, 멀티 코어 머신을 갖는 목적을 상실합니다.

ext4에 대한 경험이 그리 좋지 않습니다. 현실 세계에서 사용하기에는 아직 너무 어리다.


3
물론, 외장 드라이브이기 때문에 당신은 이것을 많이 밀지 않을 것입니다 :)
Richard

이 정보는 여전히 유용하며 귀하의 경험은 kevinclosson.net/2012/03/06/… 과 일치하는 것 같습니다 . 5 년 동안 상황이 바뀌 었는지 아는 것이 흥미로울 것입니다.
Anthony Geoghegan

빌드 시스템 (하드웨어 RAID 서버)과 워크 스테이션 및 랩톱에서도 ext4를 사용합니다. 과거 또는 최근에 귀하의 문제가 발생하지 않았습니다. 12 개의 동시 스레드를 사용하여 워크 스테이션에서 Raspberry Pi 용 Linux 커널크로스 컴파일 할 수 있으며 약 9y.o 에서 약 11 분 안에 컴파일됩니다. 워크 스테이션 (OK, SATA3 컨트롤러와 저렴한 소비자 SSD로 업그레이드했으며 2.6GHz에서 실행되는 4cores + HT가 있습니다).
Huygens

0

외부 드라이브는 CPU를 많이 사용하고 USB 버스에 크게 의존하기 때문에 XFS가 여기에서 최선의 선택입니다. 초 저전력 또는 고성능 애플리케이션을 사용할 때 이와 같은 선택은 큰 차이를 만듭니다. XFS는 내가 집에서 만든 Atom N450 기반 어플라이언스에서 훌륭하게 작동했습니다. 무려 9W를 사용하고 데이터를 잘 제공합니다.

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