유해한 USB 스틱이 걸리는 문제-LWN.net, 2013.
느린 저장 장치(예: USB 스틱 또는 미디어 플레이어)를 Linux 컴퓨터에 연결하고 대량의 데이터를 씁니다.전체 시스템이 계속 중단됩니다., 이는 몇 분 동안 지속될 수 있습니다.
이 기사에서는 커널 기본값이 간단하게 변경될 것이라고 예측합니다. 64비트 x86에서는 후기입 캐시가 기본적으로 시스템 RAM의 최대 20%까지 증가할 수 있습니다. Linus는 32비트 x86 코드의 제한 사항을 에뮬레이트하여 모든 플랫폼에서 효과적으로 이를 최대 180MB로 제한할 것을 권장합니다. 그러나 현재 Linux(v4.18)는아니요권장되는 변경 사항이 포함되어 있습니다. (비교하다리누스의 패치,도착하다v4.18의 현재 기능).
2013년 LWN 기사에서는 이 문제를 "버퍼 팽창 문제와 동등한 스토리지"라고 불렀습니다. 이제 쓰기 저장 제한( // wbt) 이라는 새로운 Linux 기능을 소개하는 2016 LWN 기사가 있습니다 . 이 기사에서는 쓰기 저장 제한을 "네트워크 스택에서 발생한 문제를 반영하는 버퍼 팽창 문제"를 완화하는 방법으로 설명합니다. 이것은 매우 유사하게 들립니다 :-).CONFIG_WBTwbt_lat_usec
특정 USB 스틱 정지 문제가 이제 해결되었습니까?
성가신 백그라운드 쓰기 저장을 줄입니다.- LWN.net, 2016
우리 중 많은 사람들이 경험한 경험이 있습니다. 상대적으로 느린 블록 장치에 많은 양의 데이터를 쓴 다음 다른 작업을 수행하려고 시도하는 것입니다. 대부분의 경우 시스템 속도가 느려지거나 일시적으로 정지되기도 하며 대부분의 데이터가 장치에 기록될 때까지 작업이 재개되지 않습니다. 대용량 메모리와 느린 I/O 장치가 있는 시스템에서는 사용 가능한 상태로 복원하는 데 시간이 오래 걸릴 수 있으며 때로는 몇 분 정도 걸릴 수도 있습니다. Linux 사용자는 이러한 행동 패턴에 눈살을 찌푸리지만 오랫동안 고집스럽게 지속되어 왔습니다. 이제 새로운 패치 세트가 상황을 개선할 수도 있습니다.
이 질문에서 영감을 얻었습니다.외부 디스크에서 과도한 읽기/쓰기 작업을 수행할 때 시스템이 지연됩니다.
답변1
문제는 "USB Stalling" 기사가 주장을 뒷받침할 어떠한 증거도 제공하지 않는다는 것입니다. "USB 스틱 정지" 문제가 실제로 존재하며 항상 유사한 보고서가 몇 가지 나오고 있습니다. 그러나 LWN 기사에서 논의된 주제는 그중 하나가 아닙니다! 그러므로 이 기사를 예로 들 수는 없습니다. 더욱이, 그것이 제공하는 모든 설명에는 결함이 있거나 적어도 불완전할 수 있습니다.
2013년에 "USB 플래시 드라이브 정지" 문제가 발생한 이유는 무엇입니까? 기존의 "I/O 더티 스로틀링 없음" 코드가 이 문제를 해결하지 못하는 이유는 무엇입니까?
연결된 답변을 요약하면 다음과 같습니다.
linux-kernel do에 보고된 문제아니요USB 스틱에 캐시된 쓰기를 플러시하는 동안 전체 시스템이 중단되는 것을 볼 수 있습니다. Artem의 초기 보고서에서는 Linux가 느린 장치에서 대규모 캐시 쓰기를 허용하여 완료하는 데 "수십 분"이 걸릴 수 있다고 불평했습니다.
말씀하신 대로 Linus가 제안한 "수정"은 아직 적용되지 않았습니다. 현재 커널 버전(v4.20 이하)에서는 대용량 RAM이 있는 시스템이 페이지 캐시에 대규모 쓰기를 작성할 수 있으므로 쓰기에 오랜 시간이 걸릴 수 있습니다.
커널에는 이미 "USB 스틱 정지"를 방지하도록 설계된 일부 코드가 있습니다. 이는 "I/O 더티 스로틀링 없음" 코드입니다. 이 코드는 2011년 LWN에도 설명되어 있습니다. 전체 후기입 캐시의 크기와 write() 호출을 제한하여 사용되는 후기입 캐시의 비율을 제어합니다.특정 지원 장치의 경우. 이는 시간이 지남에 따라 지속적으로 조정되는 복잡한 엔지니어링 시스템입니다. 나는 그것이 약간의 제한을 가질 것이라고 확신합니다. 지금까지 어떤 한계도 정량화할 수 없었습니다. 작동을 방해하는 문제를 해결하기 위해 더티 조절 코드 외부에서 다양한 버그 수정이 이루어졌습니다.
WBT는 제출 수를 제한합니다.IO 요청각 개별 장치마다. 후기입(write-back) 캐싱을 제한하지 않습니다. 즉, 더티(dirty)입니다.페이지 캐시.
Artem은 10GB가 서버에 기록되었다는 후속 보고서를 발표했습니다.내부디스크로 인해 시스템이 중단되거나 최소한 응답이 매우 오랫동안 지연됩니다. 저것이는 WBT가 해결하려는 문제와 일치합니다.
이 답변의 이전 버전에서 유지된 추가 메모:
WBT에서 설명하는 시나리오는 컴퓨터에 대량의 데이터를 쓰는 경우입니다.기본프로그램 로드 등을 위해 기본 디스크를 대화식으로 계속 사용하려는 경우
대조적으로 사람들이 "USB 스틱 정지" 문제에 대해 이야기할 때 이는 다른 디스크/외부 USB 등에 많은 데이터를 쓴 다음 해당 디스크와 관련이 없는 프로그램에서 놀라운 지연을 겪는 것을 의미합니다. 예:
"창을 옮기는 것만큼 간단한 일도 버벅거릴 수 있습니다... 원격 시스템에 대한 SSH 세션이 완벽하게 응답하기 때문에 CPU 부하가 아닙니다. 대신 원격으로 파일 시스템 IO 수행에 가까운 모든 작업이 심각하게 지연되는 것처럼 보입니다."
- https://utcc.utoronto.ca/~cks/space/blog/linux/USBDrivesKillMyPerformance
- https://utcc.utoronto.ca/~cks/space/blog/linux/FixinUSBDriveResponsiveness?showcomments
USB 스틱 문제에 관한 2013년 메일링 리스트 스레드,향후 작업의 가능성으로 더티 페이지 캐싱에 대한 장치별 제한을 언급했습니다..
WBT는 CFQ 또는 BFQ IO 스케줄러와 함께 사용할 수 없습니다. Debian과 Fedora는 기본적으로 CFQ를 사용하므로 특별한 구성이 없는 한 WBT는 USB 스틱(또는 회전하는 하드 드라이브)에 도움이 되지 않습니다.
전통적으로 CFQ는 회전하는 하드 드라이브에서 잘 작동합니다. WBT가 어디로 가는지 잘 모르겠습니다. 아마도 WBT의 가장 큰 장점은 회전하는 하드 드라이브보다 빠르지만 RAM처럼 처리하기에는 너무 느린 SSD일 것입니다.
deadline아니면 스케줄러를 사용하고 CFQ 기능을 포기해야 한다는 주장이 있을 수도 있습니다. 우분투로 전환deadline 버전 14.04에서하지만 CFQ로 다시 전환합니다.버전 17.04(열정). (CentOS 7.0은 너무 오래되고 WBT가 없는 것 같은데 SATA 드라이브와 deadline다른 모든 드라이브에 CFQ를 사용한다고 주장합니다. CentOS 7.0도 NVMe 드라이브를 지원하지만 "전혀"스케줄러를 위해.)