플래시 메모리에 Debian 10을 실행하는 단일 보드 장치가 있습니다. UBIFS를 사용하여 두 개의 볼륨(ro 루트 하나와 rw /var 하나)으로 나눕니다. 전원을 껐다 켜거나 재설정하는 조건에서는 0바이트 파일이 생성된다는 사실을 발견했습니다. 내 "설정"을 /var/opt/myApp에 저장합니다. /var에 대한 마운트 옵션을 포함하도록 변경하면 sync이러한 이벤트가 사라지는 것 같습니다.
나는 비동기가 동기화보다 낫다는 일반적인 조언을 알고 있지만 일반적으로 가능한 예외에 대한 설명이 거의 없이 "보통이지만 항상 그런 것은 아닙니다"라고 주의를 줍니다.
또 다른 해결책은 파일이 닫힐 때 플러시할 뿐만 아니라 동기화도 하기 위해 디스크에 데이터를 쓰는 모든 호출 사이트를 수정하는 것입니다(저는 Python을 사용하여 이 작업을 많이 수행합니다). 코딩/완전성 관점에서 볼 때, 설치는 sync작업량을 줄이고 보편적이기 때문에 어딘가에 동기화 보호를 추가하는 것을 놓치지 않도록 하는 것 같습니다.
또한 장치가 USB 썸 드라이브에 데이터를 저장할 수 있도록 허용합니다. 데이터가 작성되자마자 데이터를 꺼낼 때 손실을 줄이기 위해 이러한 동기화도 설치해야 한다고 생각합니다.
이것이 사용을 정당화하기에 적합한 특수 구성입니까 sync? 아니면 대체 솔루션을 사용해야 합니까?
답변1
내 요점은 다음과 같습니다. 미리 너무 장황하게 이야기해서 죄송합니다.
구체적으로 이야기할 때 ubifs우리는 항상 sync이러한/유사한 옵션 중 하나를 선택해야 합니다.
ubifs지원하다write-back caching
이는 파일에 기록된 변경 사항이 플래시 메모리에 직접 기록되지 않음을 의미합니다. 먼저 페이지 캐시에 저장된 다음 플래시 메모리에 기록됩니다. ( write buffersUBIFS의 NAND 플래시에 대해 자세히 알아보세요)
이는 쓰기 횟수를 줄여 파일 시스템 성능을 향상시킵니다.
이는 asynchronousfs의 동작입니다.
질문에서 말씀하신 것처럼 -sync 옵션을 사용하여 UBIFS를 마운트하면 파일 시스템이 생성되지만 synchronous(매번 변경 사항을 플래시에 기록) 성능이 저하됩니다.
ubifs와 같은 파일 시스템을 사용하는 경우 asynchronous쓰기가 플래시 메모리에 기록되도록 하는 책임은 애플리케이션 개발자에게 있습니다. write(2)의 매뉴얼 페이지는 다음과 같습니다:
$ man 2 write
NOTES
A successful return from write() does not make any guarantee that data
has been committed to disk. In fact, on some buggy implementations, it
does not even guarantee that space has successfully been reserved for
the data. The only way to be sure is to call fsync(2) after you are
done writing all your data.
사용
sync- 전체 파일 시스템을 동기화합니다. 최적이 아닐 수도 있음
fsync-주로 작업을 완료합니다.
fdatasync- 메타데이터(권한)가 아닌 데이터 변경 사항만 새로 고쳐집니다. 가능한 것보다 더 최적화됨 fsync(확실하지 않음)
또한 읽어보세요fsync에 관한 좋은 기사
결국 귀하의 선택은 다음과 같습니다.
- "동기화" 마운트 사용 - 성능 저하
- 위의 옵션을 사용하여 애플리케이션을 개선합니다
sync. - 애플리케이션에서 0바이트 파일을 처리합니다.
- 임시 파일을 만들고 나중에 이름을 바꿉니다.
jffs2마지막으로 동기식 파일 시스템 (NAND 플래시를 사용하는 경우 완전 동기식이 아님) 으로 전환하고 싶을 수도 있습니다 . 이것이 귀하의 질문에 대한 답변이 아니라는 것을 알지만, 어, 이렇게 쓰는 것이 좋을 것 같습니다...