안녕하세요~^^

Bulldozer 입니다~^^

오늘이 세번째 제 글을 제가 퍼오는 순간이네요 ^^;;

두번의 글을 퍼오고나서 느낀점은... 역시... 이런 쪽은 관심도가 낮구나 OTL... ^^;; 허허 ^^;;

그래서 zygote process 와 JNI 에 관한 글은 퍼오는걸 포기하고 OTL...

그나마 관심이 있을실듯 한 file system 쪽 글을 퍼옵니다~^^

오래 전에 적었던 글이기 때문에 JFS 에 대한 내용은 빠져있습니다~

이 글을 적고난 이후에 JFS 는 별도로 글을 적었었기 때문이네요~ ^^

RFS, EXT, NILFS2 에 대한 간단한 개념정도일 뿐이며, 사실상 노하우라고 할만한 것은 못되는 자료입니다.

부끄럽네요 ㅠ_ㅠ

그리고 글에도 적었는데 file system 과 관련한 내용은 구글링을 통하면 아주아주 많은 자료를

직접 찾으실 수 있을겁니다~ +_+

글 읽어주신 분들 모두 감사합니다~ ^^

항상 행복하세요~ 내일은 어린이날~~~~ ^^;;

이번에도 제 블로그에 적은 글이기 때문에 다소 건방진 말투로 느껴지실 수 있습니다 ㅠ_ㅠ

이해해주세요~ ^^;;

-------------------------------------------------------------------------------------------------

오늘은 낮에 조금 시간적 여유가 있어서 안드로이드(리눅스) 파일 시스템에 대해 알아보았다.
구글링을 통해서 생각보다 짧은 시간 안에 많은 자료를 열어볼 수 있었다.
리눅스의 파일 시스템이 스마트폰을 사용하면서 주로 들었던 rfs/ext/nilfs 보다 엄청나게 많이 존재한다는 것을 알았다.
많은 부분을 봤지만 사실 지금 안드로이드 폰의 kernel 에 주로 적용하고 있는 file system 이 아닌 부분에는
눈이 잘 가지 않아서 자세한 내용보다는 적당히 개념정리만 하고 링크를 걸어 나중에 자세히 읽으려 한다.

워낙 문외한이다보니...
한가지 file system 에 대한 내용을 이해하기 위해서는 수 많은 기본적인 단어들의 의미부터 구글링을 해야하기 때문에
시간이 많이 소요되었다.
그리고 rfs 는 아무리 구글링을 해도 자세한 정보가 나오지 않았다.
단순히 NAND flash memory 에 최적화를 시킨 file system 이라는것이 전부였다.
그리고 file system 에 대해 글을 읽으면서 기존에 알고있던 개념들과는 다른 부분들을 확인할 수 있었으며,
지금 사용하는 file system 에 대한 의문들도 몇가지 생기게 되었다.
그 의문점들은 시간을 가지고 구글링을 통해 해답을 찾아볼 생각이다.
아무래도 리눅스와 관련된 여러가지 개념들은 구글링을 해본 결과 아주 쉽게 자료를 접할 수 있었기에
구글링만으로 나와 같은 초보가 원하는 수준의 답은 얻을 수 있을듯 하다.

*. RFS
RFS(Robust File System)은 삼성에서 독자적으로 개발한 NAND flash memory 용 file system 이다.
읽어본 글들에 따르면 읽기, 쓰기, 성능, 수명을 대폭 향상시켰으며, 필요한 data 만 골라 선택적으로 구동 시키는
linux 특유의 'demand paging function' 과 서로 연동하여 NAND flash memory 의 읽기 속도를 초당 데이터 전송속도
2MB 에서 최대 4MB 까지 향상시켰다고 한다. 그리고 쓰기 속도역시 초당 2MB 로 기존의 file system 보다 10배의
성능 향상을 이루어 냈다고 한다. 그리고 data 를 영역별로 구분하여 관리하는 '자동 파일할당 테이블'을 채용하였고,
wear-leveling 기능도 가지고 있다고 한다. 그리고 기본적으로 FAT32 file system 을 기반으로 앞의 내용들과 같은
journaling, wear-leveling 등의 기능을 추가한것이라고 한다.

-- journaling --
memory 에 직접적으로 data 를 쓰지 않고 system 에 반영될 data 의 변경 사항을 원형 버퍼에 log 로 남기고, 주기적으로
file system 에 commit 시킨다. 쉽게 그냥 data 를 쓰기 전에 journal 을 통하여 변경 사항을 log 로 남김으로써, data 의
index 와 같은 역할을 하는 metadata의 손상을 막아준다고 한다. journaling 에도 여러가지 mode 가 존재하는데 이 부분은
아래 ext 계열의 file system 내용에서 나올것이므로 넘어간다. (journal = disk 의 연속된 영역에 있는 전용 순환 log)

-- wear leveling --
momory 내의 특정 block 에 data 기 지속적으로 쓰여지지 않고 골고루 분배되어 data 의 입력 및 출력이 이루어 지도록
만들어 주는 기능이다. NAND flash memory 의 경우 data 의 입력 및 출력의 회수에 따라 bad block 이 발생 할 수 있는데
발생 가능성을 낮출 수 있는 개념으로 생각이 된다. nilfs2 의 경우가 wear leveling 의 개념에서 본다면 아주 좋은듯 보인다.

*. EXT
EXT(Extended File System) 은 흔히 부두 패치와 테그라크 패치를 통해서 스마트폰을 사용하는 사람들에게는
익숙한 file system 이다. 부두 패치와 테그라크 패치는 /system, /data, /dbdata, /cache 의 4개 영역을 rfs -> ext4 converting
시킨다. 그리고 자양펌을 사용하는 경우는 /data 가 외장메모리 영역으로 치환 되면서 ext3 로 mount 된다.
주로 ext2, ext3, ext4 로 구분하여 알려져 있는데, 완전히 다른 file system 이 아니라 지속적으로 version up 이 되고 있는
하나의 file system 이다. 최신의 ext series 가 ext4 file system 이라고 보면 된다. VFS switch 를 최초로 사용한
file system 이며, ext3 부터 journaling 의 개념이 도입되었다. 그리고 ext4 에는 ext3 에서 발전하여 계층화된 접근 방식을
통해 작은 file 을 효율적으로 나타내며, extend tree 를 사용하여 대용량 file 도 효율적으로 나타낼 수 있다고 한다.
주로 사용되는 ext4 에서는 지정된 크기의 file 을 사전 할당 및 초기화가 가능하며, block 할당 지연 과 multi block 할당의
기능을 지원한다고 하는데 주로 내용은 block 에 data 를 입력 및 출력을 시키는데 최적화를 꾀하는 기능들로 보인다. 그리고 file system 내의 조각을 줄여주는 기능이 있는데, 완벽하지는 못하며 추가적으로 온라인 조각모음 도구를 지원한다고 한다.
journaling mode 에는 여러가지가 존재하는데 ext4 에서는 writeback mode(metadata 만 journaling), ordered mode(metadata 가 journaling 된 후 journal 을 바탕으로 metadata 가 기록될 때 data 도 기록), journal mode(metadata 와 data 모두 journaling) 라는 3 가지가 있다. 마지막 journal mode 의 경우는 data 가 journal 을 통과하기 때문에 i/o 속도 측면에서는 가장
느리지만 가장 안정적인 mode 라고 한다.

-- VFS switch --
상위 계층 file system 사용자의 기본 file system 에 대한 세부 사항을 추상화 하는 계층이며, VFS 를 통해서 linux 는 지정된 linux system 내에서 지원하는 여러가지 file system 을 지원할 수 있다고 한다.

*. NiLFS2
nilfs 계열의 second version 이 nilfs2 이다. 아직은 실험적인 file system 이라고 한다. nilfs 는 journaling file system 이 아니며,
LFS(Log-structured File System) 의 한 종류이다. LFS 는 우리가 스마트폰에 사용하는 NAND flash memory 에 아주 적합한 file system 이라고 한다. 그 이유는 한정적인 data i/o 회수를 모든 NAND flash memory 의 block 은 가지고 있는데,
LFS 는 전체 장치의 여러 위치에 data 를 쓰고 지우기 때문에 우수하게 wear-leveling 을 수행한다고 볼 수 있기 때문이다.
nilfs2 의 경우 garbage collection 의 기능이 강화되고, snapshot 기능을 포함하고 있다. log 형태로 구조화 되어 있기 때문에
새롭게 쓰여지는 data 는 log 의 head 부위에 쓰여지게 되며, 그 이전의 data 는 garbage collection 을 하지 않는 한 그대로
남아있게 된다. 기존의 data 가 존재하기 때문에 원하는 시점으로 돌아가서 data 를 epoch 할 수 있게 된다.
요즘 nilfs2 를 /data 영역에 적용하는 부두 nilfs2 kernel 을 갤럭시 S 유저들이 많이 사용한다. 하지만 nilfs file system 에 대해
명확히 어떠한 이유로 장점이 있는지는 잘 모르는듯 하다. 간단하게는 일단 nilfs2 는 rfs 나 ext 계역 과는 다르게 journaling 을
하지 않는다. 그리고 momory 전체를 log 구조화 하였기 때문에 block 을 찾아가면서 data 를 지우고 쓰지 않는다. 연속적으로
data 를 쭉 써내려 가버리면 된다. 그렇기 때문에 당연히 rfs 나 ext 계열보다 속도가 빠를 수 밖에 없다. 그리고 garbage 를
발생 시마다 collection 하지 않는다는 개념을 생각한다면 중간에 두 가지 일을 하지 않고 연속적으로 쓰기만 한다고 생각하면
당연히 속도가 빠르다는걸 알 수 있다. 그리고 garbage 에 대해서는 이것을 단순한 말그대로 쓰레기 라고 생각하는 듯하다.
이것은 쓰레기가 아니고, 최신의 data 가 쓰여져 있는 log 부분 이전에 기존 data 부분이 할당된 block 을 지워주는 것이다.
필요없어진 data 를 저장하고 있는 block 을 지우고 필요한 최신의 data 를 포함한 block 만을 정리하는 것이다.
protection period 지정을 통하여 필요한 시점 이내의 data 포함 block 만을 남겨두고 그 이전의 block 들을 깔끔히 지우는
것이다. garbage collection 을 도와주는 application 인 nilfs2GC 설정 application 을 이용하면 쉽게 GC 를 처리할 수 있다.
장점이 많지만 garbage 를 수동으로 처리해 줘야하고 아직은 그 안정성에 대한 확실한 검증이 부족하다는 단점을 분명히
내포하고 있는 file system 인듯 하다. 자세한 내용을 알고 나니 nilfs2 file system 이 더욱 매력적으로 느껴지는 동시에
아직은 안정성의 검증이 필요하다는 부분이 마음에 걸리는게 사실이다.

이 이외에도 exofs, jfs2, xfs, btrfs, ceph, jffs2, yaffs, cramfs 등의 많은 file system 에 대해 읽을 수 있었다.
하지만 이 모든 내용을 적기에는 큰 의미도 없고, 아직 개념정리정도만 하였기 때문에 적지 않았다.
혹시 나중에 스마트 폰에서 지금의 rfs, ext, nilfs 이외에 file system 을 적용하는 경우가 생긴다면 그때 그 file system
부분만 따로 추가하여 적을 생각이다.

-------------------------------------------------------------------------------------------------------------

초보가 자꾸 노하우 게시판에 들락날락 하는것 같아 좀 민망하네요 ^^;;

그래도 혹시 제가 알고 적어놓았던 것들이 어느 한분에게라도 도움이되고

뭔가 이런 쪽으로 좀 더 궁금증을 갖게되는 계기가 되었으면 하는 마음에 올린것이니 이해해 주세요~^^

첫 번째 글 init process-1

http://matcl.com/s/?mid=freeboard&category=9003&document_srl=2580601

두 번째 글 init process-2

http://matcl.com/s/?mid=freeboard&category=9003&document_srl=2643307

글 읽어주셔서

감사합니다~ ^_________^