ubif가 출현하기 전에 임베디드 시스템의 일반적인 관행은 보호를 위해 플래시 메모리에 다중(MTD) 파티션을 설정하는 것이었습니다. 예를 들어, 읽기 전용 파일 시스템을 포함하는 파티션은 /로 마운트할 수 있고, 구성 데이터를 위한 별도의 쓰기 가능한 파티션은 /home 또는 /data 등으로 마운트할 수 있습니다.
반면, UBI의 주요 특징 중 하나는 플래시 장치 전체에 걸쳐 레벨링을 착용하면서 논리적인 "UBI 볼륨"을 제공한다는 것입니다. 에서 인용MTD 웹사이트:
UBI는 전체 플래시 장치에 걸쳐 웨어 레벨링을 구현합니다(즉, UBI 볼륨의 하나의 논리적 삭제 블록만 지속적으로 쓰기/삭제할 수 있지만 UBI는 이를 플래시 칩의 모든 물리적 삭제 블록으로 확장합니다).
내 질문은: 읽기 전용 파일 시스템과 구성 데이터 등에 대해 별도의 UBI 볼륨을 갖는 것이 합리적입니까? 아니면 플래시 메모리 전체가 내부적으로 웨어 레벨링에 참여하므로 이는 의미가 없는 것일까요?
답변1
예, 확실히 말이 됩니다. 임베디드 시스템은 일반적으로 플래시 메모리에 두 개 이상의 별도의 부팅 가능한 이미지를 보관합니다. 이렇게 하면 하나를 지우고 업그레이드할 수 있으며, 업그레이드가 실패하면 다른 것으로 대체할 수 있습니다. 루트 파일 시스템과 구성 데이터를 동일한 볼륨에 유지하는 경우 구성 데이터를 새 볼륨으로 이동하는 것을 관리해야 하기 때문에 업그레이드 프로세스가 더 복잡해집니다(그리고 다양한 실패 시 어떤 데이터가 "남아 있는지" 추적/수정해야 함). 대체의 경우').
따라서 일반적으로 정적 프로그램 데이터와 변수 구성 데이터를 별도의 볼륨에 보관하는 것이 좋습니다. 구체적으로 UBIFS를 고려하면 몇 가지 옵션이 있습니다.
- 원래 UBI 볼륨 위에 rootfs를 squashfs에 저장합니다. MTD_UBI_BLOCK 커널 옵션을 사용하여 UBI 볼륨을 블록 장치로 제공하고 거기에서 squashfs를 마운트할 수 있습니다. 이 경우 U-Boot는 원래 UBI 볼륨에 쓸 수 있지만 UBIFS의 파일만 읽을 수 있으므로 U-Boot에서 직접 새 이미지를 쓸 수 있습니다.
- rootfs를 별도의 UBIFS로 유지하세요. UBIFS는 파일 시스템 메타데이터를 저장할 때 squashfs보다 효율성이 훨씬 낮고 rootfs가 읽기 전용인 경우 실질적인 이점이 없기 때문에 많은 추가 공간이 필요합니다.
- UBIFS 볼륨에 rootfs를 squashfs 파일로 유지하고 루프에 마운트합니다. 이는 약간의 추가 공간(rootfs 파일 자체의 메타데이터)을 사용하지만 부팅 이미지 및 구성 데이터를 위해 예약할 공간을 걱정할 필요가 없으므로 유연성이 더 높습니다. (그러나 실수로 부팅 이미지의 모든 공간을 사용하는 경우 이러한 유연성은 좋지 않을 수 있습니다.)
- MTD에 직접 rootfs를 남겨두세요. 이는 rootfs의 마모 평준화 이점을 완전히 상실하고 재활용할 삭제 블록이 적기 때문에 쓰기 가능한 볼륨에 대한 마모 평준화의 효율성을 감소시킵니다.