우리는 타사 장치에서 실행되는 소프트웨어를 작성합니다. 지원되는 장치 중 하나에서 제조업체는 플래시 드라이브에 쓰지 말라고 말했거나 지원하는 제한된 쓰기 작업을 소진할 위험이 있었습니다. 불행하게도 우리 애플리케이션의 요구 사항 중 하나는 시작하는 동안 일부 데이터를 유지하는 것이며 다른 옵션은 없습니다.
장치 내부의 드라이브가 무엇인지, 어떻게 구성되어 있는지 전혀 모릅니다. 따라서 한 가지 질문은 이 정보를 어떻게 찾을 수 있느냐는 것입니다. 내가 찾은 일부 정보는 다음과 같습니다.
bash-3.2$ df | grep mtd /dev/mtdblock5 65536 7824 57712 12% /apps
bash-3.2$ dmesg | grep -i mtd Kernel command line: root=/dev/mtdblock4 rootfstype=jffs2 rw ip=none console= mem=128M init=/sbin/init mtdparts=mtd:512k(bootloader),512k(env),2M(kernel_a),2M(kernel_b),59M(filesystem),64M(user) loglevel=3 panic=5 reboot=h 6 cmdlinepart partitions found on MTD device <NULL> Creating 6 MTD partitions on "<NULL>":
proc과 sysfs를 살펴봤지만 유용한 것을 찾지 못했습니다. 장치 환경에는 hdparam, lshw 등과 같이 내가 찾을 수 있는 유용한 도구가 설치되어 있지 않습니다.
또 다른 질문은 "쓰기 제한"이 다가오고 있는지 감지하는 데 사용할 수 있는 경험적 소프트웨어가 있습니까?
마지막으로, 부정적인 영향을 제한하기 위해 디스크에 쓸 때 관찰할 수 있는 모범 사례가 있습니까? 예를 들어 소규모 버스트 쓰기가 지속 쓰기 작업보다 낫습니까? 데이터 처리량 문제인가요, 아니면 파일 시스템 문제인가요? 파일을 닫지 않고 열고 거기에 계속 데이터를 전송하는 것이 각각의 새로운 데이터를 열고 쓰고 닫는 것보다 낫습니까?
도움을 주셔서 정말 감사합니다, 댄.
답변1
파일을 닫지 않고 열고 거기에 계속 데이터를 전송하는 것이 각각의 새로운 데이터를 열고 쓰고 닫는 것보다 낫습니까?
아니요. 버퍼링된 출력을 위해 파일을 닫거나 닫지 않으면 파일에서 데이터를 읽을 수 있는지 여부/시기에 영향을 주지만 이는 디스크에 물리적으로 기록되는 경우와 동일하지 않습니다.
즉, 파일 핸들을 플러시할 때(예: 파일 핸들을 닫음) 이제 동일한 파일에서 읽는 별도의 프로세스가 파일에 플러시한 데이터를 읽을 수 있지만 이것이 반드시 파일이 삭제되었음을 의미하지는 않습니다. 커널 출력으로 작성되었습니다. 사용 중인 경우 이미 캐시되어 있을 수 있으며 해당 캐시만 영향을 받을 수도 있습니다.
sync전체 파일 시스템에서 호출되면 시스템 디스크 캐시가 플러시됩니다(-> 장치에 기록). AFAIK 단일 파일에 대해 이 작업을 수행할 수 있는 방법이 없습니다.
또 다른 질문은 "쓰기 제한"이 다가오고 있는지 감지하는 데 사용할 수 있는 경험적 소프트웨어가 있습니까?
특히 귀하가 장치에 대해 잘 모르기 때문에 이것이 매우 의심스럽습니다. 이러한 수치는 대략적이고 보수적이므로 내 이미징 장치는 일반적으로 미리 정의된 지점에서 실패하지 않습니다. 실패할 때 실패합니다.할 수 있다어느 시점에서든 실패하면 ~N 작업 전까지 모든 것이 괜찮다고 가정하는 대신 결과적인 손상을 확인하고 방지하기 위해 할 수 있는 모든 작업을 수행하는 것이 좋습니다.
가능할 때마다 실행하십시오 fsck(파일 시스템을 마운트하기 전). 장기 실행 장치인 경우 시스템이 유휴 상태일 때 주기적으로 마운트를 해제하고 fsck하는 방법을 결정합니다.