파일을 pendrive로 복사하는 동안 PC가 정지되는 이유는 무엇입니까?


61

나는 여기에 정말로 이상한 상황이 있습니다. 적어도 대부분의 경우 내 PC는 정상적으로 작동하지만 처리 할 수없는 것이 있습니다. pendrive에서 파일을 복사하려고하면 모든 것이 정상입니다 .16-19M / s를 얻었고 꽤 잘 작동합니다. 그러나 같은 펜 드라이브에 무언가를 복사하려고하면 PC가 정지합니다. 마우스 포인터가 1 초 또는 2 초 동안 이동을 멈췄다가 약간 움직 인 후 다시 멈 춥니 다. 예를 들어 아마 로크 (Amarok)에서 무언가가 연주 될 때 소리는 기관총처럼 작동합니다. 속도는 500K / s에서 15M / s, 평균 8M / s로 점프합니다. 이것은 무언가를 pendrive에 복사 할 때만 발생합니다. 복사 프로세스가 완료되면 모든 것이 정상으로 돌아옵니다.

다른 펜 드라이브, 전면 패널의 다른 USB 포트 또는 후면의 해당 포트를 모두 시도했지만 마더 보드 (전면 패널)의 USB 핀도 변경했지만 USB 스틱을 어디에 놓아도 항상 동일합니다. 나는 다른 파일 시스템을 시도 - fat32, ext4. Windows의 랩톱에서 장치에 문제가 없습니다. 내 PC 또는 시스템의 무언가 여야합니다. 무엇을 찾아야할지 모르겠습니다. 독립형 Openbox로 데비안 테스트를 사용하고 있습니다. 내 PC는 Pentium D 3GHz, 1GiB RAM, 1,5TB WD Green 디스크입니다. 이 문제를 해결하는 데 도움이 될만한 것이 있다면 기뻐할 것입니다.

어떤 정보를 제공해야할지 모르겠지만 필요한 것이 있으면 요청하면 가능한 빨리이 게시물을 업데이트하겠습니다.

우분투 13.04 라이브 CD 에서이 문제를 재현하려고했습니다. 암호화 된 파티션 + 암호화 된 스왑을 마운트하고 펜 드라이브를 USB 포트에 연결했습니다. 다음으로 몇 가지 응용 프로그램을 시작하려고했지만 이제 RAM에 ~ 820MiB, SWAP에 약 400MiB가 있습니다. 복사에는 문제가없고 전혀 멈추지 않으며 모든 것이 정상입니다. 시스템의 결함 인 것처럼 보이지만 정확히 어디에 있습니까? 그러한 이상한 행동을 일으키는 원인은 무엇입니까?


이와 비슷한 문제가 발생했을 때 랩톱에 하드 드라이브 문제가 있었기 때문입니다. 디스크에는 불량 영역이 있었고 그 영역에서 아무것도 읽지 않을 때마다 디스크가 끝날 때까지 멈췄습니다. 살펴볼 아이디어입니다. 어쩌면 읽을 분야가 잘못되었을 수도 있습니다.
교활한

내 hdd는 괜찮습니다. 적어도 똑똑하다고 말하십시오 (전체 스캔 후).
Mikhail Morfikov

예를 들어 복사 프로세스의 IO 우선 순위를 낮추십시오 ionice -c3 cp something.tgz /media/pendrive. 이렇게하면 새로 생성 된 cp프로세스가 세 번째 (= 가장 낮은) 우선 순위 클래스 "유휴"에 놓 입니다.
n.st

나는 이것을 시도했지만 효과가 없다.
Mikhail Morfikov

@MikhailMorfikov 참고 로이 문제는 Linux 4.9에서 해결되었습니다. 여전히 수정 프로그램을 직접 테스트하지 않았습니다. YMMV.
무스 코너

답변:


85

메모리가 많은 64 비트 버전의 Linux를 사용하고 있습니까? 이 경우 문제는 Linux가 SD 카드 또는 USB 스틱과 같은 느린 장치에서 큰 쓰기로 몇 분 동안 잠글 수 있다는 것입니다. 최신 커널에서 수정되어야하는 알려진 버그입니다.

http://lwn.net/Articles/572911/ 참조

해결 방법 : 루트 문제로 :

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

/etc/rc.local64 비트 시스템의 파일에 파일을 추가했습니다 .

탄 스타 플 ; 이 변경으로 인해 이러한 장치에 대한 처리량이 줄어들 수 있으며 아마도 대기 시간과 속도 사이의 절충입니다. 이전 동작으로 돌아가려면

echo 0 > /proc/sys/vm/dirty_background_bytes
echo 0 > /proc/sys/vm/dirty_bytes

... 이것은 기본값이며, 다시 쓰기 동작은 매개 변수 dirty_ratio및 로 제어됩니다 dirty_background_ratio.

리눅스 /proc 에 익숙 하지 않은 사람들을위한 참고 사항 : 파일 은 가상 파일입니다-커널과 사용자 공간 사이의 통신 채널 일뿐입니다. 편집기를 사용하여 변경하거나 보지 마십시오. , 예를 들면 --- 대신 쉘 프롬프트를 sudo -i(우분투 맛) 또는 su root사용 echocat).

2016/04/18 업데이트 결국 문제가 여전히 여기에있는 것 같습니다. LWN.net 에서이 기사 에서 쓰기 저장 대기열에 대해 살펴볼 수 있습니다 .


3
64 비트이지만 1GiB의 RAM 만 있으며이 솔루션이 작동한다고 말해야합니다! 방금 테스트 한 결과 두 매개 변수를 설정하면 더 이상 얼지 않습니다. :)
Mikhail Morfikov

1
내 14.04 설치에서는을 uname -a반환 3.13.0-32-generic하므로 그렇습니다. 그러나 문제의 패치가 마침내 커널에 통합되었는지 여부는 확인하지 않았습니다. 나는 16GB 컴퓨터를 가지고 있으며 해결 방법이 없으면 정상적으로 작동하는 것처럼 보이지만 특히 느린 장치로는 시도하지 않았다고 말해야합니다.
Rmano

1
@ IonicăBizău --- 즉 의사 파일이, 그것을 편집하지 마십시오 vim 이제까지 . 로 루트 쉘을 sudo -i가져 와서 위에서 언급 한 명령을 사용하십시오.
Rmano

1
@Rmano 그것은 효과가 있었다! 그러나 VIM으로 편집했습니다. 감사!
Ionică Bizău

2
새로운 노트북 (16GB RAM)에서 우분투 16.04를 사용하고 있습니다. 나는이 문제에 정말로 화가났다. 당신의 솔루션은 매력처럼 작동했습니다! 아마도 커널 4.8.0-45에서 이것이 필요할 수 있다고 덧붙일 수 있습니다.
LGenzelis

3

시스템이 블록 지우기 (읽기 / 수정 / 쓰기 수행) + 블록 정렬 불량보다 작은 청크로 쓰기를 시도하기 때문에 쓰기 증폭이 될 수 있습니다.

현재 설정을 확인하려면 다음을 수행하십시오.

cat /sys/block/sd**X**/device/max_sectors

해당 장치의 홀 규칙을 조정할 수 있습니다.

전체 제품군의 USB "max_sectors"값 변경

이 경우 모든 장치에 대해 max_sector를 교체했으며 기본값 인 240 (USB 저장소)을 32K 섹터 또는 2K 섹터로 사용했습니다.

내 시스템 (Mageia 4, 3.14.24 core i7)에서 Kingston DT101 G2 16GB의 쓰기 속도 (2MB / 초)가 너무 느려서이 작업을 수행해야했습니다.

vi /usr/lib/udev/rules.d/81-udisks_maxsect.rules

그리고 추가하십시오 :

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="32678"

그리고 dd쓰기 속도가 3 배 증가했습니다. mc cp아마도 10-20 배 증가 (8192 번째 섹터에서 첫 번째 파티션을 시작하고 64k 정렬 클러스터로 다시 포맷 한 후) :

fdisk -u /dev/sdh # make DOS compat off if on
mkfs.vfat /dev/sdh1 -n KINGSTON16G -s 128 **-R 4592*** and use *fsck.vfat -v /dev/sdh1

정렬을 확인하려면 ([데이터 시작 섹터]가 128 (클러스터 크기)의 배수 여야 함)를 확인하십시오. 필요한 경우 예약 된 섹터 수 (-R)를 조정하십시오.

기본 max_sectors (240)는 저렴한 새 드라이브 중 일부에서 높은 쓰기 증폭을 일으키는 것으로 보입니다. 그러나 이러한 높은 설정에 매우주의를 기울이면 2048 섹터 (아마도 1M 소거 블록)에서 비슷한 효과가 나타납니다.

SUBSYSTEMS=="scsi", ATTR{max_sectors}=="240", ATTR{max_sectors}="2048"

오래된 USB 장치는 모두 제대로 작동하는지 테스트하십시오. 보다 구체적으로 규칙 파일에서 공급 업체 / 모델 속성을 사용하십시오.


1

하드웨어 대 소프트웨어

나는 USB 썸 드라이브에서 이와 비슷한 이상한 문제를 겪었고, 연구에서 거의 항상 드라이버 문제 또는 PC / 마더 보드 내의 특정 하드웨어입니다.

나는 동일한 하드웨어 인 여러 시스템을 가지고 있기 때문에 이것을 알고 있습니다. 하나는 문제 없이이 작업을 수행 할 수 있지만 다른 하나는 문제가 나타납니다.

무엇을해야합니까?

당신은 옵션이 정말 제한되어 있습니다. 수행 할 수있는 유일한 작업은 시스템에 최신 BIOS / 펌웨어가 설치되어 있고 최신 버전의 disto 패키지가 있는지 확인하는 것입니다.

내가 제안 할 수있는 것 외에는 다른 복사가 진행되는 동안 파일을 복사하지 않으면 서 이러한 상황을 피할 수 있습니다.

이와 같은 것들이 당신을 괴롭히는 성격의 유형을 가지고 있다면, Linux의 다른 배포판을 시도하고 문제를 일으키는 단계를 반복 할 수 있습니다. 이것은 위에서 설명한 것처럼 배포판 특정 문제인지 하드웨어 문제인지 제거합니다. 그것은 작은 위안이 될 것이지만, 나는 항상 모래에 머리를 묻지 말고 사물을 알고 싶어합니다.

다른 거있어?

당신이 진정 강박 관념 strace이라면 시스템 호출이 멈추고있는 상황에서 시스템을 잡기 위해 복사를하고있는 응용 프로그램을 실행할 수 있습니다. 명령 행에서도이를 수행 할 수 있어야합니다.

$ strace -o cp1.log cp -r /path/to/dir1 /path/to/usb/. 

그런 다음 다른 하나를 시작하십시오.

$ strace -o cp2.log cp -r /path/to/dir2 /path/to/usb/. 

이 작업을 수행하는 동안 시스템이 제대로 작동하지 않을 수 있으며 운이 좋으면 해당 로그 파일 중 하나에서 연기가 발생할 수 있습니다.


나는 항상 하나의 파일 복사 인스턴스 만 사용합니다. BIOS를 업데이트 (2008)했으며 그 이후로 최신 버전은 없습니다. 나는 그것이 BIOS가 아니라고 생각합니다. 내 데비안 배포판도 테스트 지점으로 업데이트되었습니다. 나는 사용하려고 시도 strace하고 거의 즉시 얼어 붙었습니다. 그래서 몇 초 기다렸다가 프로세스를 종료했습니다. 1MB의 로그가 있지만 읽을 수 없습니다. 무엇을 찾아야할지 모르겠습니다. pastebin.com/u29RvqgC에서 확인할 수 있습니다 . 전체 로그는 아니지만 (500Kb로 제한됨) 끝에있는 것과 비슷한 줄만있었습니다. 우분투 라이브 CD 로이 문제를 재현하려고합니다.
Mikhail Morfikov

라이브 CD 테스트에 관한 질문을 업데이트했습니다.
Mikhail Morfikov

@MikhailMorfikov-당신이 기대할 수있는 일이 거의 끝났다고 생각합니다. 당신의 하드웨어는 꽤 낡았으며 (2008), 위에서 설명한 것 이상으로 할 수있는 일은 많지 않습니다.
slm

그러나 구형 PC조차도 문제없이 파일을 복사 할 수 있습니다.
Mikhail Morfikov

@MikhailMorfikov-나이가 유일한 요소는 아니지만 펌웨어 업데이트 또는 이전 하드웨어 소프트웨어 업데이트의 가능성은 낮습니다.
slm
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.