%EB%8A%94%20%EB%AC%B4%EC%97%87%EC%9E%85%EB%8B%88%EA%B9%8C%3F.png)
저는 2013년 Mel Gorman이 보낸 다음 이메일을 이해하고 싶습니다.
https://lore.kernel.org/lkml/[이메일 보호됨]/
그러나 여전히 문제가 있습니다. 모든 더티 페이지가 느린 장치에 의해 백업되는 경우에도 더티 제한으로 인해 결국 더티 페이지 밸런싱이 중단됩니다. [...] 의식적으로든 무의식적으로든 내 데스크톱 응용 프로그램은 일반적으로 이러한 문제로 고통받지 않습니다. [...]USB 스틱이 연결되어 있을 때 쓰기가 많은 작업을 무의식적으로 피하고 있을 수도 있습니다.
다음 접근 방식을 권장합니다. 여기는아니요아직 구현되지 않았으며 Linux 5.1에 있습니다.
나는 여전히 우리가 "다시 쓴 데이터의 N초 이상을 망칠 필요가 없다"는 원칙을 바탕으로 bdi당 쓰기 저장 추정치를 사용해야 할 것이라고 생각합니다. 쓰기 저장 속도는 다양한 이유로(여러 IO 소스, 무작위 및 순차 등) 다양할 수 있으므로 구현하기가 그리 간단하지 않습니다. 따라서 어느 시점에서 우리는 목표 창 내에 있다고 생각하지만 완전히 틀린 생각입니다. 더티 비율은 확실하게 보장되며 더티 쓰기 저장 추정치는 최선의 노력이며 경우에 따라 잘못될 수 있습니다.
이메일에 언급된 커널 코드의 "미해결 문제"는 무엇입니까? Gorman은 왜 기존 코드가 정체될 것으로 예상합니까?
예를 들어, 최신 PC가 한 번에 5~10초 이상 완전히 정지될 수 있는지 알고 있습니까? 또는 열려 있는 창이 일시 중지된 것처럼 보일 수 있습니까(계속 커서를 이동하고 창을 이동할 수 있음)?
이메일에 잘못된 것으로 알려진 부분이 있나요?
현재 Linux 커널에 여전히 동일한 문제가 있습니까?
나는 매우 유사한 증상에 대한 보고를 본 적이 있습니다.크리스 시벤만(Chris Siebenmann), 2017년.
Mel Gorman의 이메일은 보관된 토론의 일부입니다. LWN.net은 이 토론에 대해 "유해한 USB 스틱 정지 문제"라고 썼습니다. 단순히 그 기사를 흉내내는 것은 피해주세요. 이에 대해서는 아래에서 설명합니다.
Test("무엇을 시도해 보셨나요?")
나는 커널을 실행한다 5.1.6-200.fc29.x86_64. 8G Imation USB 드라이브가 있습니다. dd if=/dev/zero of=/var/run/media/alan/imation/test bs=1M status=progress약 4MiB/s로 수렴되었습니다. 이는 내 메인 HDD가 달성할 수 있는 것보다 약 25배 더 낮습니다. 현재 실행하면 grep -E 'Dirty|Writeback' /proc/meminfo특정 시간에 약 1GiB의 캐시된 쓰기로 수렴됩니다. 8GiB의 물리적 RAM이 있습니다.
( Writeback한 번에 하나 또는 두 개의 MiB만 표시됩니다. 또한 더티 수준은 다를 수 있습니다. 이전에는 MemTotal(예: 물리적 RAM)의 대략적인 비율로 설정되었습니다. 현재 더티 수준은 대략적인 비율로 설정되어 있습니다. 메모리 사용 가능).
USB 쓰기 중에 시스템이 계속 응답합니다. 창을 이동할 수 있고, 웹 브라우저를 계속 사용할 수 있습니다...
USB 쓰기 전과 도중에 기본 HDD에서 다음 대기 시간 테스트를 실행했습니다. 두 경우 모두 동일한 시간이 소요됩니다: 약 3-4초:
mkdir "$HOME"/tmp
cd "$HOME"/tmp
time bash -c "for (( i=0; i < 100; i++ )); do dd if=/dev/zero bs=16k count=1 of=latencytest status=none; sync latencytest; mv latencytest latencytest2; done"
"유해한 USB 스틱 정지 문제" -?
비정상적으로 LWN의 경우 충분히 주의 깊게 읽지 않았습니다. 이 문제에 대한 LWN의 기사는 두 가지 다른 문제를 통합합니다. 아래 링크에서 이 주장을 길게 인용합니다. 독자의 피로를 최소화하기 위해 아래에서 관련 세부정보를 선택했습니다.
2013년에 "USB 플래시 드라이브 정지" 문제가 발생한 이유는 무엇입니까? 기존의 "I/O 더티 스로틀링 없음" 코드가 이 문제를 해결하지 못하는 이유는 무엇입니까?
보관된 이메일에서는 해당 개수의 "더티"(기록되지 않은) 페이지 캐시가 축적되어 몇 초 동안 지속되는 일시 중지에 대해 설명합니다. 그러나 구체적인 내용에 대해서는 약간 혼란 스럽습니다.
이것원래 불만 사항매우 명확한. 리누스 토발즈(Linus Torvalds)는 보다 구체적인 예를 들어 이 불만을 반복합니다. 예를 들어, 임의의 1GB 파일을 linux.iso마운트된 USB 플래시 드라이브에 끌어서 놓습니다 . 드라이브가 10MB/s를 쓸 수 있다고 가정합니다. time sync파일 시스템에 플러시 캐시 쓰기를 실행 하고 100초가 걸리는 것을 확인했습니다. 쓰기 캐시가 너무 큰 것 같은 느낌이 듭니다!
이 결과는 RAM이 8GB 이상인지, 커널이 64비트인지에 따라 달라집니다. 쓰기 캐시는 RAM의 20%로 제한됩니다. 극적인 부분은 32비트 커널을 비교할 때 제한이 RAM의 처음 1GB를 기준으로만 계산된다는 것입니다. 따라서 sync64비트 커널로 전환하면 해당 부분에서 8배(또는 16배 또는...) 대기 시간이 나타날 수 있습니다. 나는 이것에 충격을 받고 좌절감을 느끼는 것을 이해할 수 있습니다 :-).
ㅏ두 번째 불만출시되기도 했습니다. 다음은 "실속 근처" 시나리오입니다.메인 시스템 디스크오직.
두 번째 경우의 메커니즘은 더 복잡합니다. 기본 디스크와 기본 디스크의 커널 IO 스케줄러 내의 요청 대기열을 채웁니다. 20초 이상의 "더티" 캐시를 허용하지 않더라도 여전히 문제가 발생할 수 있습니다. 두 질문 사이에는 약간의 중복이 있지만.
두 번째 경우와 유사한 문제를 찾는 것이 훨씬 쉬워 보입니다. 시스템 중지 측면에서 볼 때, 내 /home파일 시스템에 계속 쓰는 것은 훨씬 더 위험해 보입니다(여기에는 Ctrl+Alt+F6을 사용하여 텍스트 VT로 전환하는 것을 방지하거나 지연하는 것이 포함됩니다). /나는 최근에 이것을 보았다. 최근:"가상 머신 이미지를 복제할 때마다 시스템의 응답 속도가 매우 느려집니다."