ELF:An Efficient Log-Structured Flash File System For Micro Sensor Nodes

1. ELF:An Efficient Log-Structured Flash File System For Micro Sensor Nodes Hui Dai, Michael Neufeld, Richard HanUniversity of Colorado at Boulder 한국외국어대학교 컴퓨터및정보통신공학과 데이터베이스 & 정보시스템 실험실 석사과정 박원주

2. 목차 • Abstract • Introduction • Related Work • Design Overview • Implementation Issues • Performance Evaluation • Discussion and Future Work • Conclusion

3. Abstract

4. Abstract • 센서 node 환경 • 매우 제한된 자원 • 한정된 실시간 메모리 • 한정된 저장공간(persistent storage) • 제한된 에너지 • 플래시 저장 장치를 사용 • 전통적인 하드디스크의 방식과의 차이 • ELF • 센서 node에 최적화된 로그구조기반 file 시스템 • 효율적인 메모리 사용 • 저전력의 연산 수행 • 센서에서의 file 연산에 공통적인 형태의 지원 • ex) file에 데이터를 추가/수정 • Wear-leveling • Garbage collection

5. 2. Introduction

6. Introduction • 센서 네트워크에서의 제한된 자원 • RAM의 부족 • 센서 데이터, 실행코드를 위한 공간 • 저장 장치의 사용 • 회복이 가능한 메커니즘 설계 • RAM 실행에 따른 방해 축소 • 견고성 향상 • 현재 대부분의 센서 node 플랫폼에서 플래시 메모리 사용 • 플래시 메모리에서 ELF • file에 대한 기본 연산을 구현 • efficient, reliable, flexible한 file 시스템을 구현

7. 3. Related Work

8. Log Structured File Systems • 로그 기반의 file 시스템 • cache의 사용 • 처리량을 최대로 하기 위해 cache를 사용하여 많은 수의 데이터 블록을 모아서 처리 • 최소화된 seek 시간과 작은 file에 대한 성능 향상 • cache 크기 • cache 크기의 증가는 read/write 성능의 증가 • 플래시 메모리 • seek 시간은 아주 적음 • 새로운 페이지를 접근하는데 고정된 시간 지연

9. Flash File System • eNVy • 트랜잭션 형태의 응용프로그램을 사용할 때 좋은 성능 • 대용량의 플래시 메모리와 배터리가 포함된 SRAM으로 구성 • RAM과 플래시 사이에 큰 대역폭의 병렬 데이터 path를 구성 • 두 가지의 cleaning 정책을 결합해서 사용 • FIFO 와 locality gathering • MFFS (microsoft flash file system) • MS-DOS용 플래시 file 시스템 • 가변 길이의 데이터에 사용 • 주소 포인터로 디렉토리와 file간에 연결됨

10. Flash File System • Translation Layer • file 시스템과 플래시 메모리 사이에 위치 • 논리적인 블록에 대해 각 섹터 정보를 유지 • JFFS, JFFS2 • 저널링된 메타데이터 정보 유지를 통해 오류 회복 • write 연산마다 로그에 기록 • 가상 블록과 실제 플래시 메모리 사이에 매핑테이블 정보를 유지 • ELF에서의 적용 • 모든 write 연산에 대해 새로운 node를 생성하지 않음 • write-modify 연산에만 로그 적용하여 node를 생성함 • 센서node 환경을 위해 메모리 소비시간을 줄임 • best-effort 신뢰성를 제공

11. Sensor Storage and File System • DCS & Dimension • 센서 네트워크에서 분산된 이벤트 저장을 위해 사용 • 하위 단계에서의 저장장치는 간단한 circular 로그 구조로 구현 • Matchbox • 센서 네트워크에 가용한 file 시스템 • 동시에 여러 file을 열수 있음 • wear-leveling과 file관리를 위한 원격 접근 가능 • 코드 크기 (10K) • 메모리 최소 사용량 (362byte) • append 연산만을 지원하고 random 연산(write-modify)을 지원하지 않음 • 회복 중 file의 무결성을 위해 CRC를 사용

12. 4. Design Overview

13. Design Goals • 플래시 메모리를 이용하는 센서 node에서 실용적(practical), 효과적(efficient)이고 신뢰성 있는(reliable) file 시스템 • Goals • 플래시 메모리에 간단한 file 연산을 수행 가능 • wear-leveling을 통한 수명의 연장 • 적은 메모리 사용공간 • 공통의 센서 file 연산을 최적화 • 과도한 에너지 소비 방지 • 선택적인 best-effort 데이터 신뢰성 제공

14. File Access Behavior on Sensor Nodes • sensor data • 센서 시스템에서 기록되는 대부분의 데이터 • 수정 없이 순차적으로 write • 새로운 공간 확보를 위해 주기적으로 삭제 • configuration data • post-deployment중에 수정이나 업데이트 • 자주 변경되지 않음 • 일반 데이터보다 더 높은 수준의 신뢰성 요구 • binary program image • 일부 update되거나 변경된 이미지 • 가장 높은 신뢰성 필요 • 각각 다른 접근 방법과 신뢰도 요구사항이 필요

15. Persistent Storage Capabilities on Sensor Nodes • 플래시 메모리의 일반적인 특성 • on-chip cache • cache내의 데이터는 플래시 메모리에 flush되기 전에 수정 가능 • read 성능 ≒ 800 KB/sec , write 성능 ≒ 10 KB/sec

16. Persistent Storage Capabilities on Sensor Nodes • on-chip cache 에서의 write 연산 • 데이터를 on-chip cache에 쓰여짐 • 플래시 메모리의 페이지에 on-chip cache의 내용을 flush하려는 명령을 보냄 • 플래시메모리의 페이지를 소거 한 뒤 소거된 페이지에 flush • mica2에서 EEPROM • RAM보다 느리고 플래시 메모리만큼 양이 많지 않음 • ELF에서는 EEPROM의 이점을 취함 • 제한된 크기의 RAM • wear-limit 한 플래시 메모리 • boot 시간과 file 접근 시간을 줄임

17. Log-Structured File System Techniques in ELF • 전통적인 로그 구조 file 시스템 • write 연산마다 연속적으로 새로운 로그 엔트리를 생성 • 로그의 크기가 무한히 커질 수 있음 • write-append • 연산마다 로그 엔트리를 생성하지 않음 • 각 file에서 같은 페이지에 대한 각 append 연산을 cache 모아서 사용 • write-modify • 연산마다 새로운 플래시 페이지와 새로운 로그 엔트리를 생성 • 일반적인 garbage collection • 빈 플래시 페이지를 재할당하는 방법으로 wear-leveling이 구현 • 각 플래시 페이지의 메타 데이터에 write counter 유지

18. ELF Architecture Overview • Resource Abstraction • 실시간 메모리에 유지 • file open, cleaning 정책, 기타 ELF설정 데이터가 RAM/플래시메모리/EEPROM에 저장됨 • General File Operation • 모든 file/디렉토리 연산의논리적인 추상화 • ELF Maintenance Task • 시스템 관리 태스크의 추상화 • 디렉토리 구조의 스냅샷, EEPROM내의 file 메타데이터, garbage collection task

19. 5. Implementation Issues

20. ELF의 데이터 구조

21. On-Flash Data Structures : Physical Nodes • 플래시메모리에서 ELF의 상위단계 레이아웃은 단일 로그 포맷 • ELF의 로그는 연속된 physical node로 구성 • 새롭게 생성되는 node는 로그의 끝에 추가 • 3가지 형태의 physical nodes를 지원 • file inodes, common nodes, directory entries • ELF_DIR • 기본적인 디렉토리 연산과 간단한 디렉토리 구조를 지원 • 디렉토리 이름, 포함된 file과 서브 디렉토리의 수, node 상태 플래그 등의 필드 • ELF_FILE • file운영에 필수적인 메타데이터 포함 • file의 내용은 node의 메타데이터 다음에 저장 • file 이름, inode번호, node 상태 플래그 등이 저장 • ELF_COMMON • 일반적인 수정, 삭제, rename 연산을 수행하기 위해 이 node를 생성, node 리스트 끝에 추가 • metadata 정보를 유지 • file에서의 데이터 시작 위치(start offset), 가지고 있는 데이터의 길이, 이어진 file의 inode번호, 포함된 데이터의 버전 정보 등

22. On-Flash Data Structures : Per-Page Metadata • mica2에서의 플래시 메모리는 256byte의 데이터 페이지와 8byte의 페이지당 메타데이터를 유지 • CRC • 페이지의 데이터 무결성을 검사 • 전체 페이지 또는 CRC를 제외한 메타데이터 중 택일 • nextPage • 같은 물리 node에 속하는 다음 페이지의 포인터 • 하나 이상의 페이지를 사용하는 데이터가 존재할 경우 사용 • flags • 페이지의 상태(free, in_use, dirty) • writeCounter • 페이지가 다시 쓰여진 횟수 • magicNumber • 차후를 위해 남겨둠

23. In-Memory Data Structures : File Abstraction • 파일의 메타데이터 • file의 길이, inode 번호, 참조 카운터, physical node abstraction리스트에 대한 포인터, 파일의 버전 등이 저장 • write 성능향상을 위해 캐시를 사용(default 64bytes) • 플래시 메모리의 수명 연장 • 동시에 열수 있는 file의 수가 제한 • 시스템 시작 시에 파일시스템의 root에 해당하는 virtual file abstraction을 만듬

24. In-Memory Data Structures : Node Abstraction • RAM 사용량을 최소화하기 위해 physical node의 필수 요약 정보만을 유지 • 파일 내에서의 위치, 다음 physical node abstraction 포인터 • File Descriptor • 응용 프로그램을 수행하기 위해 file이 필요 • file abstraction, 현재 file의 offset ,open mode로 구성

25. In-EEPROM Data Structures and Related Operations • file에 대한 빠른 접근를 위해 EEPROM에 디렉토리 정보를 저장 • checkpoint 영역과 system information 영역으로 구분 • System Reboot • sensor node에서의 reboot 절차 • 초기화 작업, 플래시 스캐닝 • graceful reboot전에 RAM의 디렉토리 구조, 파일의 현재상태를 EEPROM에 저장 • crash에 의해 reboot되는 경우 EEPROM의 checkpoint를 사용하여 복구 성능 향상

26. File Operation in ELF • 표준 file 연산지원 • open(), close(), read(), write(), lseek(), delete(), truncate() • 기본 unix 디렉토리 연산 지원 • mkdir(), rmdir() • 임의 위치 읽기 / 쓰기를 지원

27. File Operation in ELF : Open and Create 새로운 fileabstracttion 생성 빈 플래시 페이지를 할당 physical node생성 RAM에 physical node abstraction과 file abstraction을 생성 RAM의 abstraction을 유지 RAM에 file abstraction이 있는지 확인 ERROR 반환 반환

28. File Operation in ELF : Append • file의 physical node에 대해 업데이트 지연 정책을 사용 완료 버퍼가 모두 차면 버퍼의 내용을 플래시 페이지의 끝에 write RAM에 버퍼를 설정 하여 append데이터를 caching 가용한 공간이 없으면 새로운 플래시 페이지를 할당 이전 페이지의 메타데이터의 nextPage를 새로 할당받은 페이지로 설정 새로할당 받은 플래시 페이지에 write

29. File Operation in ELF : Write(modify) offset A 체크 중복되는 data가있는지 체크 플래시 메모리할당 physical node생성 version number 필드 1 증가 physical node list에 추가 RAM에 새 nodeabstraction 생성

30. File Operation in ELF : Read/seek , Rename , Deletion • Read/seek • read 연산은 여러 개의 sub-read로 구성 • Random read를 위해 multiple node로 구성된 두 개의 포인터 사용 • Rename • 새로운 physical node 생성 • Deletion • Rename의 과정과 유사, garbage collection 과정을 통해 삭제

31. Resource Management and Garbage Collection • Resource Management • 전통적인 file 시스템은 free/dirty/used list 사용하여 저장 공간 관리 • List 알고리즘의 최적화 • 새롭게 할당되는 블록은 가능할 경우 기존 블록과 결합 • 둘 이상의 file이 열려 있는 상태에서 시뮬레이션 결과잘 수행되지 않음 • ELF는 bitmap이 적합 • 복잡한 알고리즘이 필요하지 않음 • 일정한 메모리를 사용 • 연결 리스트를 사용할 경우 메모리의 동적 할당이 필요

32. Garbage Collection • 간단한 garbage collection 알고리즘만 사용 • 빈 플래시 페이지의 수가 경계값 미만이면 수행 • cleaner • 삭제 되었거나, rename되었거나 사용할 수 없는 파일에 대해 reclaim • 페이지 내부의 link와 bitmap의 해당 bit를 수정 • 빈 공간이 부족하면 de-fragmentation을 실시 • 수명을 10000번으로 가정한다면 쓰기 횟수가 9000 이상이면 “unusable”로 페이지에 표시 • cleaner의 RAM사용 • defragmentation 을 사용하지 않을 경우 : 10 bytes • defragmentation 을 사용할 경우 : 40 bytes

33. Crash Recovery • 선택적인 에러 회복 제공 • Checkpoint • 가장 최근에 연산이 완료된 위치를 정의 • ELF에서는 file의 상태만을 저장 • Roll-forward • 각 연산은 추가로 수정된 데이터를 기록 • 가능한 많은 데이터를 회복하기 위해 사용 • checksum을 사용하여 메모리가 손상되었는지 확인 • ELF는 최근 연산에 대한 snapshot 기록(15byte) • inodeNum, action, cur_version, highest_version • Append: 시작 오프셋과 추가된 길이 • Modify: 시작 오프셋과 수정된 길이 • Rename: 버전 • Obsolete: 버전

34. 6. Performance Evaluation

35. Sequential Read Performance • 최대 처리량을 측정 • 500kb 센서 로그 file로 메모리를 채움 • 순차적으로 읽기 연산 수행 • ELF와 Matchbox와의 성능을 비교

36. Sequential Write Performance • ELF의 appending 연산의 성능을 측정 • 임의의 file을 생성하고 16bytes의 센서 데이터를 전체 메모리가 채워질 때까지 append 연산 수행 • E1: append 연산에 RAM 버퍼링 없이 수행, 전체 free 영역에 bitmap 저장(256byte): 64byte bitmap만 사용 • 0~128byte로 buffering 크기를 늘림

37. Random Read Performance • 임의의 위치에서 데이터의 일부를 읽음 • 두 가지의 시나리오로 수행 • 크고 연속적인 file이 저장되어 있을 경우 • 4번의 modify 연산 후 4개의 물리node로 구성되 있을 경우

38. Random Write Performance • modify 연산이 발생했을 경우를 테스트 • 플래시에 100Kb의 로그 file 생성, 임의의 offset에서 0~300kb의 새 데이터로 overwrite

39. Wear Levelling Performance • 시뮬레이션을 통해 테스트 수행 • 4개의 file 생성 • 하나의 4kb file 생성 후 업데이트 빈도가 적음 • 두 개의 로그 file 생성 후 번갈아가며 64bytes씩 append 됨 • 10,000번 쓰기를 수행하는 동안, 20Kbytes file을 생성하고 삭제 • 메모리가 full이 되면, 임의의 데이터를 선택해 삭제

40. Energy Consumption • 쓰기 연산에 의해 가장 많은 에너지가 소비 • read 4~10mA • write 15~35mA • 쓰기 연산의 최소화가 에너지 절약에 효율 • 16byte 단위로 append 될 경우 256byte를 채우기 위해서는 16번의 쓰기 연산 수행 • 32byte의 cache 사용으로 쓰기 횟수를 줄임

41. 7. Discussion and Future Work

42. DISCUSSION AND FUTURE WORK • ELF에서 사용하는 circular 버퍼 형태의 기술은 센서 네트워크에서 사용하는 다양한 응용 프로그램을 만족시키지 못함 • 센서 네트워크의 특징상 자주 발생하는 연산(reboot, file open, file create)을 잘 처리하도록 디자인되지 않음 • 버퍼링은 ELF의 성능과 효율성에 중요한 역할을 하지만 신뢰성 측면에서 비용을 부담해야 함 • 센서 node에서 파일의 신뢰성을 보장하기 위한 latency 비용 혹은 energy 비용을 측정하지 않음 • 데이터 압축

43. 8. Conclusion

44. Conclusion • 마이크로 센서 node를 위한 신뢰성 있고 효율적인 file 시스템을 디자인 • 센서 node의 제한된 자원에 최적화 • 센서 네트워크의 작동에 최적화 • wear-leveling 지원 • 효율적인 회복 알고리즘 지원