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

나는 여기에 정말로 이상한 상황이 있습니다. 적어도 대부분의 경우 내 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가 있습니다. 복사에는 문제가없고 전혀 멈추지 않으며 모든 것이 정상입니다. 시스템의 결함 인 것처럼 보이지만 정확히 어디에 있습니까? 그러한 이상한 행동을 일으키는 원인은 무엇입니까?

메모리가 많은 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사용 echo과 cat).

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

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

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

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 장치는 모두 제대로 작동하는지 테스트하십시오. 보다 구체적으로 규칙 파일에서 공급 업체 / 모델 속성을 사용하십시오.

하드웨어 대 소프트웨어

나는 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/. 

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