컴퓨터에 문제가 없을 수도 있습니다. 그 자체로는 문제가 없습니다. 그러나 USB 플래시 트랜지션 레이어에는 자체 쓰기 프로세서가있어 모든 쓰기 작업을 매핑하여 90 % 결함이있는 플래시 칩에 대한 보상을해야합니다. 당신은 그것을 범람하고 당신의 버퍼를 범람 한 다음 전체 버스를 범람 한 다음에 갇혀 있습니다. 결국 모든 것이 있습니다. 직관적이지 않은 것처럼 들리지만 실제로 필요한 것은 I / O를 차단하는 것입니다. FTL이 속도를 설정 한 다음 계속 유지해야합니다.

(FTL 마이크로 컨트롤러 해킹시 : http://www.bunniestudios.com/blog/?p=3554 )

위의 모든 답변이 작동해야하므로 이것이 “나도!” 다른 것보다 : 나는 완전히 거기에 있었다. rsync의 –bwlimit arg (2.5mbs는 단일 오류없이 실행하기에 좋은 장소 인 것처럼 보였으며 더 많은 쓰기 방지 오류가 발생했습니다)로 내 문제를 해결했습니다. rsync는 전체 파일 시스템으로 작업했기 때문에 특히 내 목적에 적합했습니다. 파일이 많았 기 때문에 rsync를 두 번째로 실행하면 첫 번째 실행 문제가 모두 해결됩니다. 2.5MB 이상으로 가감 속).

여전히 단일 파일에는 실용적이지 않다고 생각합니다. 귀하의 경우 dd set to raw-write로 파이프 할 수 있습니다. 한 번에 하나의 대상 파일 만 처리 할 수 ​​있습니다 (단일 파일은 물론 전체 블록 장치 일 수 있음).

## OBTAIN OPTIMAL IO VALUE FOR TARGET HOST DEV ##
## IT'S IMPORTANT THAT YOUR "bs" VALUE IS A MULTIPLE ##
## OF YOUR TARGET DEV'S SECTOR SIZE (USUALLY 512b) ##
% bs=$(blockdev --getoptio /local/target/dev)

## START LISTENING; PIPE OUT ON INPUT ##
% nc -l -p $PORT | lz4 |\
## PIPE THROUGH DECOMPRESSOR TO DD ##
>    dd bs=$bs of=/mnt/local/target.file \
## AND BE SURE DD'S FLAGS DECLARE RAW IO ##
>        conv=fsync oflag=direct,sync,nocache

## OUR RECEIVER'S WAITING; DIAL REMOTE TO BEGIN ##
% ssh user@remote.host <<-REMOTECMD
## JUST REVERSED; NO RAW IO FLAGS NEEDED HERE, THOUGH ##
>    dd if=/remote/source.file bs=$bs |\
>    lz4 -9 | nc local.target.domain $PORT
> REMOTECMD

데이터 전송시 netcat이 ssh보다 약간 빠르다는 것을 알 수 있습니다. 어쨌든 다른 아이디어는 이미 취해진 것입니다. 왜 그렇지 않습니까?

[편집] : 다른 게시물에서 lftp, scp 및 ssh에 대한 언급을보고 원격 사본에 대해 이야기하고 있다고 생각했습니다. 현지인이 훨씬 더 쉽습니다.

% bs=$(blockdev --getoptio /local/target/dev)
% dd if=/src/fi.le bs=$bs iflag=fullblock of=/tgt/fi.le \
>    conv=fsync oflag=direct,sync,nocache

[EDIT2] : 마감일 : ptman이 댓글에서 5 시간 정도 나에게 이겼다는 것을 알게되었습니다.

분명히 승수로 성능을 위해 $ bs를 조정할 수 있지만 일부 파일 시스템에서는 대상 fs의 섹터 크기의 배수가 필요할 수 있으므로 명심하십시오.

답변

while true do
  dd if=infile of=outfile bs=4096 count=... seek=... skip=...
  sleep 5
done

vm.dirty_background_ratio = 3
vm.dirty_ratio = 10