파일 복사에서 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.