파일 복사에서 Linux가 Windows 10보다 30 배 빠른 이유는 무엇입니까?


20

총 100k + 항목의 20.3Gig 파일 및 폴더가 있습니다. Windows 10에서 하나의 디렉토리에 모든 파일을 복제했으며 3 시간의 복사 시간이 걸렸습니다. 끝난.

다른 날, 나는 리눅스 페도라 24에서 부팅했고 같은 폴더와 bam을 받았다! 같은 장소이지만 다른 디렉토리에 복제하는 데 5 분 밖에 걸리지 않았습니다.

리눅스가 왜 그렇게 빠른가? 그리고 Windows는 매우 느리게 진행됩니까?

비슷한 질문이 있습니다.

(Ubuntu) Linux 파일 복사 알고리즘이 Windows 7보다 낫습니까?

그러나 받아 들여진 대답은 꽤 부족합니다.


"Windows"또는 "Linux"를 사용하여 파일을 복사하지 않고 해당 운영 체제 각각에서 실행되는 특정 프로그램을 사용합니다. 프로그램은 사용하는 방법과 장단점이 다양합니다. 어느 것을 사용 했습니까? 그리고 어떻게?
— kreemoweet

5
@kreemoweet : 운영 체제도 마찬가지입니다. Windows NTFS는 대부분의 다른 파일 시스템에 비해 많은 작은 파일을 처리하는 데 어려움을 겪고 있습니다.
— user1686

2
그리고 Windows 팬 허에서 좋은 downvote. 파일 복사는 단순하지만 비즈니스에서의 데이터 백업부터 과학적 연구에 이르기까지 많은 응용 프로그램이 있습니다. 예를 들어, CERN에는 처리 할 페타 바이트 단위의 데이터가 있으며 느린 복사는 허용되지 않습니다.
— Jones G

같은 링크에서-하단에서 두 번째 답변을 확인하십시오. Linux는 모든 파일을 사용 가능한 RAM에 캐시하고 가능한 경우 디스크에 기록합니다. 따라서 파일이 더 빨리 보이는 이유는 지금 읽기만하고 가능한 경우 쓰기 만하면됩니다.
— 다리우스

@DominicGuana 파일 시스템이 그 역할을합니다 (ext3 / ext4는 한 번에 100Mb의 청크를 할당 할 수 있습니다). Windows에서 바이러스 백신이 (느린) 역할을 할 수 있다고 생각 했습니까? SLAC 데이터 수집 흐름과 유사한 문제에 대한 BTW (1 수준 트리거 후 데이터가 너무 많음) HDD에 병렬로 쓰는 법을 배웠습니다.
— Hastur

답변:


25

기본 요소는 UI 시스템 (그래픽 부분), 커널 자체 (하드웨어와 통신하는 내용), 데이터가 저장되는 형식 (예 : 파일 시스템) 등 전체 시스템의 몇 가지 주요 구성 요소로 분류됩니다. ).

거꾸로 돌아 가면 NTFS, 한동안 Windows에 대한 사실상의 역할을 해왔고, 주요 Linux 변형에 대한 사실상의 ext파일 시스템 은 파일 시스템입니다. NTFS 파일 시스템 자체는 Windows XP (2001) 이후로 변경되지 않았으며 파티션 축소 / 치료, 트랜잭션 NTFS 등의 많은 기능이 OS의 기능 (Windows Vista / 7 / 8 / 10)입니다. 및 하지 자체를 NTFS. ext파일 시스템은 그것의 마지막 주요 안정적인 릴리스를 (한 ext4자체가 지배하는 방법과 위치 파일을 사용하는 경우, 액세스 무엇 파일 시스템 때문에 2008 년) ext4는 NTFS, 속도에 대한 개선을 알 수 있습니다 가능성이 기회가; 그러나 사용한 경우 ext2속도가 비슷하다는 것을 알 수 있습니다.

또한 한 파티션이 다른 파티션보다 작은 청크로 포맷되어있을 수도 있습니다. 대부분의 시스템의 기본값은 4096 byte 1 , 2 클러스터 크기이지만 ext4파티션을 16k 3 과 같은 형식으로 포맷 하면 ext4시스템에서 읽을 때마다 데이터의 4 배, NTFS 시스템 ( 저장된 내용에 따라 4 배의 파일을 의미 할 수 있음) 위치 / 방법 및 크기 등). 파일 조각화도 속도에 중요한 역할을합니다. NTFS는 파일 ext시스템과 파일 조각화를 매우 다르게 처리 하며 100k + 파일을 사용하면 조각화가 발생할 가능성이 큽니다 .

다음 구성 요소는 커널 자체 (UI가 아니라 실제로 하드웨어와 통신하는 코드, 실제 OS)입니다. 여기에는 솔직히 큰 차이가 없습니다. 두 커널 모두 디스크 캐싱 / 버퍼링과 같은 특정 작업을 수행하여 읽기 및 인식 된 쓰기 속도를 높이도록 구성 할 수 있지만 이러한 구성은 일반적으로 OS와 상관없이 동일한 절충안을 갖습니다. 예를 들어, 캐싱은 복사 / 저장 속도를 크게 증가시키는 것처럼 보이지만 캐시 쓰기 도중 전원이 끊기거나 USB 드라이브를 꺼내면 실제로 디스크에 기록되지 않은 모든 데이터와 이미 기록 된 데이터가 손실 될 수 있습니다 디스크에.

예를 들어, 많은 파일을 Windows 및 Linux의 FAT 형식 USB 드라이브에 복사하십시오. Windows에서는 10 분이 걸리고 Linux에서는 10 초가 걸립니다. 파일을 복사 한 직후 드라이브를 꺼내어 안전하게 제거하십시오. Windows에서는 시스템에서 즉시 배출되므로 USB 포트에서 드라이브를 제거 할 수 있지만 Linux에서는 실제로 드라이브를 제거하려면 10 분이 걸릴 수 있습니다. 이는 캐싱 때문입니다 (즉, Linux는 파일을 RAM에 쓴 다음 백그라운드에서 디스크에 기록한 반면, 캐시없는 Windows는 파일을 디스크에 즉시 기록했습니다).

마지막은 UI (사용자가 상호 작용하는 그래픽 부분)입니다. UI는 멋진 그래프와 멋진 막대가있는 예쁜 창 일 수 있습니다. 복사되는 파일 수와 파일의 크기 및 소요 시간에 대한 일반적인 아이디어를 제공합니다. UI는 또한 인쇄되지 않는 콘솔이 될 수 있는 당신이 일을 끝낼 때를 제외하고 정보를 표시합니다. UI가 각 폴더와 파일을 먼저 조사하여 파일 수와 파일 크기를 결정하고 실제로 복사를 시작 하기 전에 대략적인 추정치 를 제공 해야하는 경우 UI가 필요하기 때문에 복사 프로세스가 더 오래 걸릴 수 있습니다 이 작업을 수행. 다시 말하지만, OS에 관계없이 마찬가지입니다.

디스크 캐싱 또는 클러스터 크기와 같은 일부 항목을 동일하게 구성 할 수 있지만 실제로는 시스템 작동을 위해 모든 부분이 어떻게 연결되는지, 특히 코드가 실제로 얼마나 자주 업데이트되는지에 따라 달라집니다. Windows OS는 Windows XP 이후 먼 길을 왔지만 디스크 하위 시스템은 몇 년 동안 모든 버전에서 OS에서 TLC를 많이 보지 못한 영역입니다 ( Linux 에코 시스템 과 비교하여 새로운 FS가있는 것으로 보입니다) 또는 자주 개선).

좀 더 명확 해지기를 바랍니다.


내 의견으로는 끔찍한 대답이 내려졌다. 차이가없는 곳에 차이점을 도입하고 있습니다. 아무도 다르게 분할 된 드라이브의 성능을 묻지 않았습니다. 물론 질문은 "다른 모든 것이 평등하다"는 교훈에 중심을 둔다. 초당 16 기가 바이트 이상의 기본 읽기 속도로 원하는 방식으로 8 nvme raid0에 대해 fs를 선택할 수 있지만 Windows 파일 사본은 항상 1.4-1.5 기가 바이트로 항상 최대치입니다. 캐싱, fs, 파티션과는 관련이 없지만 Windows OS 제한과 관련이 있습니다.
— Matthias Wolf

@Matt RAID 어레이를 어떤 파일 시스템 에 포맷하고 있습니까? NTFS 인 경우 속도 저하를 설명 할 수 있습니다. 그러나 제공 할 추가 정보가있는 경우 특히 핵심 Windows OS에 소스 코드 (조립품 덤프가 아님)가있는 경우 관련 답변을 추가 할 수 있습니다. 왜 느려짐이 발생했는지 직접 설명해야합니다 (특히 관심이있을 것입니다!).
— txtechhelp

나는 ntfs를 사용하는데, Windows 서버에서 fs로 더 나은 옵션은 무엇입니까?
— Matthias Wolf

나는 MSFT에 연락하여 많은 토론을하고 수년 동안 많은 것을 시도했으며 각 시스템에 100Gb nics가 있고 Mellanox 프로파일 링 도구 당 다른 모든 트래픽이 연결이 완벽하게 작동하고 있음을 보여 주었음에도 불구하고 1.5GB / 초를 초과하지 않았습니다. 94-95Gb / sec 처리량. 리눅스 머신들 사이에는 속도 저하가 없지만, 윈도우 OS 머신이 참여하자마자 병목 현상이 나타납니다
— Matthias Wolf

단일 파일 전송, 모든 단일 스레드에 대해 이야기하고 있습니다. 순수한 OS 기반의 하드웨어 병목 현상은 없습니다.
— Matthias Wolf 10
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.