디스크에 데이터 쓰기를 지연시키는 이유는 무엇입니까?

쓰기가 완료될 때까지 실제로 기다릴 필요 없이 프로그램에 속도의 환상을 제공할 뿐입니다. 파일 시스템을 동기화 모드로 마운트하고(즉시 쓰기가 가능함) 모든 것이 얼마나 느린지 확인하십시오.

때로는 파일이 일시적으로만 존재하는 경우도 있습니다. 프로그램이 일부 작업을 수행하고 작업이 완료되자마자 파일을 삭제합니다. 이러한 쓰기를 지연하면 애초에 쓰지 않고 벗어날 수도 있습니다.

IO 오류로 인한 쓰기 실패 위험은 없나요?

아, 물론이죠. 이 경우 일반적으로 전체 파일 시스템이 읽기 전용 모드로 전환되어 모든 지옥이 풀립니다. 그러나 이는 매우 드물게 발생하므로 전반적인 성능 이점을 잃는 것은 의미가 없습니다.

이 접근 방식의 철학은 무엇입니까?

효율성(디스크 기능 활용도 향상) 및 성능(쓰기 후 즉시 애플리케이션을 계속 사용할 수 있음)

데이터가 즉시 기록되지 않는 이유는 무엇입니까?

가장 큰 장점은 운영 체제가 대역폭 사용량을 향상시키기 위해 연속 쓰기 작업을 자유롭게 재정렬하고 병합할 수 있다는 것입니다(작업 감소 및 검색 감소). 소수의 대규모 작업을 요청할 때 하드 디스크 성능이 더 좋아지는 반면, 응용 프로그램에는 다수의 소규모 작업이 필요한 경향이 있습니다. 또 다른 확실한 최적화는 동일한 블록이 짧은 시간 내에 여러 번 기록될 때 운영 체제가 마지막 쓰기를 제외한 모든 것을 삭제할 수도 있고, 영향을 받는 파일이 그 동안 삭제되는 경우에도 일부 쓰기를 모두 함께 삭제할 수 있다는 것입니다.

이러한 비동기 쓰기가 완료되었습니다.뒤쪽에시스템 write호출이 반환되었습니다. 이는 사용자에게 두 번째이자 가장 확실한 이점입니다. 비동기 쓰기는 데이터가 실제로 디스크에 저장될 때까지 기다리지 않고 작업을 계속할 수 있기 때문에 애플리케이션 속도를 높입니다. 동일한 유형의 버퍼링/캐싱이 읽기 작업에도 구현됩니다. 여기서 최근 또는 자주 읽은 블록은 디스크에서 다시 읽는 대신 메모리에 보관됩니다.

IO 오류로 인한 쓰기 실패 위험은 없나요?

불필요한. 이는 사용된 파일 시스템과 적절한 중복성에 따라 다릅니다. 데이터를 다른 곳에 저장할 수 있다면 I/O 오류는 무해할 수 있습니다. ZFS와 같은 최신 파일 시스템은 불량 디스크 블록을 자가 복구할 수 있습니다. 또한 I/O 오류로 인해 최신 운영 체제가 중단되지는 않습니다. 데이터 액세스 중에 이러한 문제가 발생하면 영향을 받는 응용 프로그램에 보고하기만 하면 됩니다. 구조적 메타데이터 액세스 중에 이러한 문제가 발생하여 파일 시스템이 위험에 빠지면 읽기 전용으로 다시 마운트되거나 액세스할 수 없게 될 수 있습니다.

또한 운영 체제 충돌, 정전 또는 하드웨어 오류가 발생하는 경우 약간의 데이터 손실 위험이 있습니다. 이것이 데이터가 디스크에 있다는 것을 100% 확신해야 하는 애플리케이션(예: 데이터베이스/금융 애플리케이션)이 덜 효율적이지만 더 안전한 동기 쓰기를 수행하는 이유입니다. 성능 영향을 완화하기 위해 많은 애플리케이션은 여전히 ​​비동기 쓰기를 사용하지만 사용자가 명시적으로 파일을 저장할 때(예: vim, 워드 프로세서) 결국 동기화합니다.

반면에 대다수의 사용자와 애플리케이션은 동기 쓰기에서 제공되는 보안이 필요하지도 신경 쓰지도 않습니다. 충돌이나 정전이 발생할 경우 유일한 위험은 일반적으로 마지막 30초의 데이터가 손실되는 것입니다. 금융 거래가 포함되거나 비용이 30초보다 훨씬 더 크다는 것을 의미하지 않는 한, 비동기 쓰기(환상은 아니지만 매우 현실적임)를 통해 얻을 수 있는 엄청난 성능 향상이 위험보다 훨씬 더 큽니다.

마지막으로, 동기 쓰기는 기록 중인 데이터를 보호하기에 충분하지 않습니다. 애플리케이션에서 무슨 일이 일어나더라도 데이터가 손실되지 않도록 해야 하는 경우 화재 및 홍수와 같은 재해를 견딜 수 있도록 여러 디스크와 여러 지역에 걸쳐 데이터 복제가 필요합니다.

비동기식, 버퍼링된 I/O는 Linux와 Unix 이전에도 사용되었습니다. 유닉스에도 있고, 모든 브랜치에도 마찬가지입니다.

Ritchie와 Thompson이 CACM 논문에 쓴 내용은 다음과 같습니다.UNIX 시간 공유 시스템:

사용자에게는 파일 읽기와 쓰기가 모두 동기화되고 버퍼링되지 않은 것처럼 보입니다. 즉, 읽기 호출에서 반환된 후 즉시 데이터를 사용할 수 있고, 반대로 쓰기 후에는 사용자의 작업 공간을 재사용할 수 있습니다. 실제로 시스템은 파일에 액세스하는 데 필요한 I/O 작업 수를 크게 줄이는 상당히 정교한 버퍼링 메커니즘을 유지합니다.

---

귀하의 질문에 다음과 같이 작성하셨습니다.

IO 오류로 인한 쓰기 실패 위험은 없나요?

예, 쓰기가 실패할 수 있으며 프로그램은 이를 결코 알지 못할 수도 있습니다. 이는 결코 좋은 일이 아니지만, I/O 오류로 인해 시스템 패닉이 발생하는 경우 그 영향을 최소화할 수 있습니다(일부 운영 체제에서는 이를 구성할 수 있습니다. 시스템은 계속 실행될 수 있지만 파일 시스템은 패닉이 발생하지 않습니다). )이 마운트되지 않았거나 읽기 전용으로 마운트되었습니다. 그런 다음 사용자는 해당 파일 시스템의 데이터가 의심스럽다는 알림을 받을 수 있습니다. 디스크 드라이브를 사전에 모니터링하여성장 결함 목록이는 드라이브 오류를 나타냅니다.

BSD가 추가됨fsync시스템 호출을 통해 프로그램은 계속하기 전에 파일 데이터가 디스크에 완전히 기록되었는지 확인할 수 있으며 후속 Unix 시스템은 동기 쓰기를 수행하는 옵션을 제공합니다. GNU dd에는 conv=fsync명령이 종료되기 전에 모든 데이터가 기록되도록 하는 옵션이 있습니다 . 버퍼링된 데이터를 쓰는 데 몇 분이 걸릴 수 있으므로 속도가 느린 이동식 플래시 드라이브에 쓸 때 유용합니다.

파일 손상의 또 다른 원인은 정전 등으로 인한 갑작스러운 시스템 종료입니다. 거의 모든 현재 시스템에서 지원됨깨끗한/더러운파일 시스템에 표시하십시오. 이 플래그는 다음과 같이 설정됩니다.깨끗한이는 일반적으로 시스템 종료 중에 실행되거나 더 이상 쓸 데이터가 없고 파일 시스템이 마운트 해제되려고 할 때 수동 호출에 의해 실행됩니다 umount. fsck파일 시스템이 완전히 닫히지 않은 것을 감지하면 시스템은 일반적으로 재부팅 시 실행됩니다 . .

이는 Linux에만 국한된 것이 아니며페이지 캐시(리눅스는 잘한다). 당신은 또한 볼 수 있습니다http://linuxatemyram.com/;따라서 파일에 쓰고 몇 초 후에 다시 읽는 경우 일반적으로 디스크 I/O가 필요하지 않습니다.

가장 큰 장점은 많은 시스템에 RAM이 많고 그 중 일부는 커널에서 캐시로 사용될 수 있다는 것입니다. 따라서 특정 파일 작업에서는 이 캐시를 활용할 수 있습니다. 또한 디스크 I/O 시간은 RAM보다 훨씬 느립니다(일반적으로 SDD의 경우 수천 배 느리고 HDD의 경우 거의 백만 배 느림).

애플리케이션 코드는 이 캐시에 대한 힌트를 제공할 수 있습니다.posix_fadvise(2)&미친 웨스(2)