What is Journaling and Logs

casaubon · 2002-11-06, 07:57 AM

저널링과 로그란 무엇인가

What is Journaling and Logs

Dear Diary, now I'm going to make a change...
by: David K. Every Oct 16, 2002

기술적으로, 저널링이란 저널, 혹은 로그 작성의 개념을 뜻한다. 기본적으로 저널링은 FBI나 비서가 하는 일로서 매일매일의 사소한 일도 적어내려감을 의미한다. 나날의 일상을 기록하는 것이 사생활 침해랄 수도 있지만, 재판에서 어떤 일이 일어났는지 정확히 알아야할 때, 혹은 뭔가 필요한 일을 잊었을 때에는 요긴하게 사용할 수 있다.

기본적으로 저널드 파일링 시스템(Journaled Filing System)은 하드 드라이브에서 같은 일을 한다. 문제는 의미에 따라서 저널링의 종류가 많다는 데에 있다.

Journaling

파일을 하나의 길다란 종이, 그것도 이것 저것 쓰여진 종이라고 생각해 보자. 종이라고 생각해보자. 뭔가 이미 써내려갔다면 여기에 무한정 계속 쓸 수는 없다. 즉, 위가 다 찼으면 아래로 계속 내려가야하는데, 앞에 것에 덮어 쓰는 것도 생각할 수 있다. 따라서 기본적으로 파일의 앞에있는 부분에 대한 변화는 그 파일의 끝이 아닌 한, 전체 파일의 재작성을 요구한다. 적어도 앞이나 중간에 뭔가 더 쓸 때마다, 더 쓸 공간이 필요하기 때문이다. 끝까지 술술 써내려갔다면 역시 문제가 생기지 않는다. 파일은 끝에서 자라나지, 중간이나 앞에서 더 자라나는 건 아니다. `이미 잔뜩 써 놓았으니 새 내용을 또 쓸 수가 없다. 또 쓸려면, 덮어 써야 한다. 즉 겹쳐진다. 계속 적어 내려가더라도 이미 써있던 내용과 겹쳐져 버리고, 그런 겹쳐 쓰기가 반복된다. 따라서 기본적으로 파일 앞 부분을 변화시키면, 쓸 공간을 얻기 위해 전체 파일을 재작성 해야 하며, 이 재작성은 파일의 중간이건 어디에서건 내용을 추가시킬 때마다 끝까지 반복된다. 이런 식으로 파일의 끝까지 재작성을 반복하면 문제 없다. 파일 크기는 끝에서 늘어나지, 중간이나 앞에서 늘어나지 않는다.

그러므로 변화시킬 때마다, 전체 파일을 재작성해야한다는데, 만약 쓰는 도중에 쓸 힘을 잃거나 소프트웨어적인 문제가 생기면 어떻게 될까? 간단한 문제는 아니다. 사고가 나기 직전까지의 상황을 그대로 유지하면서 아직 쓰여지지 않은 부분도 반영하고, 어떤 부분은 날라가 버리는 등 파괴 상태(corrupt state)가 되버린다. 당연히 이런 상황을 좋아하는 사람은 없다.

이런 "부분 완전" 에러는 큰 문제다. 예기치 못하게 버그가 생기고 퍼포먼스가 떨어지기 때문이다. 해결 방안은 여기서 시작한다.

Programmer fixes it

문제를 고치는 일반적인 방법은 바로 "프로그래머에게 맡겨라"이다. 읽기/쓰기 접근을 위해 파일을 열거나 이전 파일을 덮어서 작성하는 대신, 프로그래머는 읽기-전용으로만 원래 파일을 열 수 있다. 저장할 때마다 새로운 파일이 생겨나고 여기에 작성하는 것이다. 파일 작성을 마치면 이전 파일의 이름을 고치고(보통 "to be deleted"로 바꾼다), 새로운 파일에 원래 파일의 이름을 준 다음, 이전 파일을 지운다.

이런 식으로 정렬을 했다면, 데이터를 잃을 가능성은 줄어들며, 설사 뭔가 잃더라도 새로운 버전과 이전 버전을 교환만 하면 되므로 전체 파일에는 영향을 끼치지 않는다. 정확한 경로를 알고 있다면 되짚어가서 찾아낼 수도 있을 것이다.

물론 좋은 방법이다. 프로그래밍도 잘만 하면 버그의 99%는 줄일 수 있다지만, 완벽하진 않다. 또한 수고가 많이 들기 때문에 누구나 이렇지는 못한다. 더구나, 이전 파일의 이름을 바꿨지만, 아직 새 파일의 이름을 다시 지정해주지 않는다거나, 아직 이전 파일을 지우지 않았다거나, 생각할 수 있는 실수의 가능성은 무한하다. 즉, 1%라도 버그는 존재할 수 있다.

앞의 경우, 데이터의 관계를 잃어버리기에, 찾아서 고쳐내기가 힘들어진다. 뒤의 경우는 드라이브상에 이전 파일이 남아있기 때문에 원하지 않는 파일(orphaned temp files)로 채워지기에, 고칠 수야 있지만 완벽할 수는 없다. 이럴 때는 "log"를 작성해서 고치는 방법이 있다. 로그가 남겨져있다면 무슨 일이 일어나더라도 어디를 고쳐야할 지 정확하게 알 수 있기 때문이다. 바로 이 방법을 저널링(혹은 로깅)이라고 하며, 보통 파일 시스템의 저널라이징의 의미가 쓰이지만, 다른 종류의 저널라이징에 대해서도 설명해보겠다.

Journaled Files

새로 작성해야하는 경우는 모두 피하는 프로그램도 있다. 왜 모든 파일이 하나의 저널이 될 수는 없을까? 파일을 복잡한 구조로 유지하기보다는 파일이 작성되는 곳을 문서의 전체 구조로, 즉, 저널이라 로그로 하기 때문이다. 기본적으로 모든 명령은 디스크에 작성되며, 사실 이런 프로그램들은 "저장" 명령을 갖고 있지 않고 끊임없이 자동 저장된다. 어떻게보면 무한한 명령취소 가능 파일링 시스템이랄 수 있다.

파일을 열때, 이런 저널 파일을 읽거나 문서 전체가 빠르게 타이핑되고, 철자 실수나 수정은 다음에 이뤄지는 광경을 쳐다보는 느낌은 참 신기하다. 즉, 당신의 파일은 최종 결과물의 구조가 아니라, 최종 결과물에 이르는 이벤트의 시퀀스인 셈이다.

이런 시스템은 파일을 덮어서 작성하는 것이 아니라 그저 계속 추가하는 것이기 때문에 가벼우며, 그렇기 때문에 어떤 작업물이건 잃을 수 없다. 시간에 걸쳐 작성되기 때문에, 잃었으리라 여기는 건 가장 최근에 작성한 명령/키스트록일 경우가 많다. 가장 최근 것이라면 어떻게든 기억하고 있을 때도 많다.

하지만,누구나 생각할 수 있는 단점이 있다. 저널은 쓸모없는 것까지 전부다 추적한다. 스무 장을 친 다음에 10 장씩 나누고, 몇 번 재구성한다고 가정해보자. 보통의 파일에서 최종 결과물은 10장 크기이다. 하지만 저널이 개입될 경우 30~40장에 이르르며, 읽을 때마다 모든 커맨드를 실행시킬 때까지 기다려야한다. 결코 효율적이지 못하다.

따라서 저장할 때 필요한 커맨드만 작성하는 혼합법도 있다. 저장하기 전에 똑같은 것을 서너번 편집한다면 마지막 것만 남겨서 일을 효율적으로 처리할 수 있다.(마지막 것만 중요하기 때문이다) 하지만 풀 저널링(Full Journaling)은 앞의 개념이다. 사실 저널링 파일 시스템을 얘기할 때는 보통 풀 저널링을 얘기하지는 않는다.

Hybrid Filing

오픈독(OpenDoc)은 깔끔한 혼합 시스템, 혹은 백지(컨셉트 도큐먼트) 상에 작성하는 식이었다. 기본적으로 오픈독은 저장, 혹은 스냅숏을 찍을 때까지 끊임없이 저널을 작성한다. 저장되면 전체 버전, 혹은 파일의 스냅숏을 저장하며, 스냅숏은 전체 파일 취급을 받아 시퀀스 순서가 아닌 로직 순서대로 배열된다. 그래서 원래 파일이 스냅숏을 첨부하면, 저널은 삭제되고 다시 시작하는 식이다.

이제 각 파일은 실제로는 수많은 파일로 이뤄져있다. 각자 자신의 영역(fork)에 저장되기 때문이다. 포크화된 파일링 시스템에서는 각자 연결된 파일이 수없이 많이 존재한다. 따라서 파일을 드래그하면 여기에 관계된 모든 파일을 드래그하는 것이며, 이 파일은 각 포크가 sub-파일로 들어간 특수한 폴더처럼 보면 된다.

이렇게 파일의 이전 버전/스냅숏을 되돌아볼 수 있다는 것, 버전 컨트롤(version control)이 OpenDoc / Bento 기반 시스템의 강점이었다. 사실 예전 오퍼레이팅 시스템 중에 하나인 DEC의 VMS가 유사하지만 원시적인 버전 컨트롤을 채택했었고 이 기능은 상당수의 호평을 받았다. 오픈독의 버전 컨트롤은 훨씬 균형잡혀있었고 현대적이었다. 오픈독에서는 원하는 경우 이전 버전을 삭제하거나, 놔두는 등의 선택을 할 수 있었고, 선택한 명령에 대해 히스토리를 작성한다.

마지막 포크(저널)는 마지막 스냅숏과의 차이점만을 기록하기에 결코 커다랗지 않으며, 차이가 클 경우에는 스냅숏을 저장하면 된다. 각 파일은 수많은 부분(포크)으로 나뉘어져있기 때문에 무슨 일이 일어나더라도 백업으로 다른 부분은 계속 존재한다. 즉, 저널화되면 모든 변화를 계속 저장(별도로 수동 저장이 아니다)하여서 무한한 수준의 명령 취소를 할 수 있다.

하지만 오픈독은 정치적인 이유로 죽고말았다. 오픈독과 함께 그 아이디어도 죽었지만, 좋은 아이디어는 결국 돌아오게 마련이다. 요즘 저널링 파일 시스템을 이야기하는 사람들 태반은 오픈독에 대해 듣지 못했거나, 오픈독이 어떤 식이었는지 모를 것이다. 그래서 다른 이야기들을 한다.

Journaled Filing Systems

파일을 만들 때, 파일에 대해 영향을 끼치는 수많은 명령들도 조심해야한다. 파일을 복사하거나 이동, 이름짓기 등은 모두 파일에 영향을 끼친다. 이런 명령들은 전부 OS 책임이며, 대부분의 프로그래머들은 OS가 무엇을 할 지 숙지해놓아야한다.

유닉스 계열에서는 하이레벨은 무시하고 로우레벨만 이야기하는 성향이 있기 때문에, 이들이 얘기하는 저널 시스템은 프로그래머와 프로그램이 하는 저널링이 아니라 OS의 저널링(혹은 제일 낮은 로우레벨에서의 저널링)이다.

오퍼레이팅 시스템(파일링 시스템)이 파일을 복사한다거나 이동, 이름짓기를 시도하면, 파일에 변화가 생긴다. 이런 변화는 로우레벨 작성, 혹은 변화를 요구하기 때문에, 시스템 충돌은 이러한 시퀀스에서 생겨나고, 충돌에 의해 데이터를 잃게 된다.

보통, 유닉스(혹은 다른 OS들) 상에서는 부분적으로 고쳐낼 수 있는 부분이 많다. 가령 부팅할 때, fsck라는 유틸리티가 있다. Fsck는 기본적으로 디스크상의 모든 파일과 프라그먼트를 검색하고 어떤 부분이 비정상인 지를 확인한 다음에 고치거나, 회복할 수 없는 경우에는 지운다. 디스크가 크고 파일이 많다면 이 과정도 오래걸린다. 대부분의 오퍼레이팅 시스템은 비슷한 유틸리티를 갖고 있으며, 이걸 좀더 예쁘게 처리해주는 써드 파티 유틸리티도 많다.

그런데 파일링 시스템이 저널화되면, 데이터-손실 현상이 일어나기 전에 오퍼레이팅 시스템이 별도의 로그 파일이나 저널을 스스로 작성한다. 그에맞는 처리가 뒤이어 일어나고 최종적으로는 로그파일이 정리된다. 이때 시스템이 어느 때라도 충돌을 일으킨다면 전체 디스크를 스캐닝하기보다는 로그 파일을 조사해서 변화한 지점을 알아내고 재처리할 수 있다. 기존의 방법보다 훨씬 빠르며, 데이터 손실도 거의 없다.

하지만 대가가 없진 않다. 뭔가 변할 때마다 로그를 우선 작성해야하기 때문이다. 사소한 변화도 로그를 업데이트하기 때문에 로그는 디스크와 어느 때라도 싱크가 이뤄줘야한다. 따라서 대부분의 저널 시스템은 비 저널 시스템보다 느리다.

또한 알 수 있다시피 파일링 시스템이 제일 하부 레벨에서까지 저널화된다고 애플리케이션(프로그램)도 안전하게 저널화한다는 뜻은 아니다. 각 애플리케이션들에 대해서는 프로그래머들이 저널화시켜야한다.

Conclusion

저널링이나 로그에는 이야기거리가 무척 많음을 알았을 것이다. 저널링에는 많은 단계, 수많은 종류가 있으며, 애플이 MacOS X의 저널화에 대해 논의하고 있다는 소식이 필자로서는 무척 기쁘다. 물론 속도나 신뢰성에 따라 사용할 수도 사용하지 않을 수도 있다. 사실 OS 때문에 일어나는 데이터 손실은 이미 무척 낮아졌다. 오히려 애플리케이션이 걱정이다.

유닉스 버전의 저널링은 그 문제의 일부만 해결할 뿐이다. 필자는 하이-레벨 저널링과 버전 컨트롤을 어느정도 수준으로 프로그래머에게 돌리는 가에 관심이 있다. 물론 여기에도 여러 단계가 있음은 물론이다. 언제인가는 이 영역도 모두 바뀌어서, 하이레벨로 저널을 조사할 날이 오리라 희망한다. 안정성과 보안의 진전은 좋은 소식임에 틀림없다.

http://www.igeek.com/browse.php?id=1093

sjahn · 2003-11-26, 04:03 AM

요즘 Mac OS X 10.3 팬서에 저널닝을 온,오프할수 있는
기능이 있어 궁금했는데, 그 내용에 대한 좋은 글이었습니다.

감사합니다.

지금 이것을 적용시킬지 말아야 할지 논의가 많은데 한번
테스트 해야 겠습니디다.

casaubon · 2003-11-26, 05:50 PM

저널링에 대한 해석 부분에 중요한 내용이 누락되어 있었습니다. 바로 덮어쓰기에 대한 '반복' 부분이 굉장히 모호하게 되어 있었는 데요. ilovja 님의 지적덕분에 다시 깔끔하게 할 수 있었습니다. 고친 부분은 전과 마찬가지로 위와 같이 코드 처리 하였습니다. ilovja 님, 정말 감사드립니다. ^^;

어차피 모두 같이 보는 글이니만큼 최대한 올바르게 번역해야 합니다. 원문과 비교해서 보시는 분들은 주저말고 이게 아닌갑다 싶으시면, 댓글을 쓰시거나 쪽지를 보내주세요. 절대로 미안해 하실 일이 아닙니다. 제 눈의 대들보는 제가 못 보죠. 제 잘못을 고치려면 여러분의 도움이 필요합니다.

endovert · 2003-11-26, 06:05 PM

항상 좋은글 감사드립니다~

그나저나 OpenDoc은 부활 안할런지 모르겠네요....
ActiveX를 대적할만한 뭔가가 있어얄텐데 말이죠....

OpenDoc에 저널링까지 포함돼 있었다는건 또 처음 알았네요~
역시 OpenDoc~! 시대를 넘 앞서나갔어~~

2002-11-06, 07:57 AM	#1
casaubon Moderator Registered: Sep 2001 My Mac: MacBook Air Posts: 2,137 오프라인	저널링과 로그란 무엇인가 저널링과 로그란 무엇인가 What is Journaling and Logs Dear Diary, now I'm going to make a change... by: David K. Every Oct 16, 2002 기술적으로, 저널링이란 저널, 혹은 로그 작성의 개념을 뜻한다. 기본적으로 저널링은 FBI나 비서가 하는 일로서 매일매일의 사소한 일도 적어내려감을 의미한다. 나날의 일상을 기록하는 것이 사생활 침해랄 수도 있지만, 재판에서 어떤 일이 일어났는지 정확히 알아야할 때, 혹은 뭔가 필요한 일을 잊었을 때에는 요긴하게 사용할 수 있다. 기본적으로 저널드 파일링 시스템(Journaled Filing System)은 하드 드라이브에서 같은 일을 한다. 문제는 의미에 따라서 저널링의 종류가 많다는 데에 있다. Journaling 파일을 하나의 길다란 종이, 그것도 이것 저것 쓰여진 종이라고 생각해 보자. 종이라고 생각해보자. 뭔가 이미 써내려갔다면 여기에 무한정 계속 쓸 수는 없다. 즉, 위가 다 찼으면 아래로 계속 내려가야하는데, 앞에 것에 덮어 쓰는 것도 생각할 수 있다. 따라서 기본적으로 파일의 앞에있는 부분에 대한 변화는 그 파일의 끝이 아닌 한, 전체 파일의 재작성을 요구한다. 적어도 앞이나 중간에 뭔가 더 쓸 때마다, 더 쓸 공간이 필요하기 때문이다. 끝까지 술술 써내려갔다면 역시 문제가 생기지 않는다. 파일은 끝에서 자라나지, 중간이나 앞에서 더 자라나는 건 아니다. `이미 잔뜩 써 놓았으니 새 내용을 또 쓸 수가 없다. 또 쓸려면, 덮어 써야 한다. 즉 겹쳐진다. 계속 적어 내려가더라도 이미 써있던 내용과 겹쳐져 버리고, 그런 겹쳐 쓰기가 반복된다. 따라서 기본적으로 파일 앞 부분을 변화시키면, 쓸 공간을 얻기 위해 전체 파일을 재작성 해야 하며, 이 재작성은 파일의 중간이건 어디에서건 내용을 추가시킬 때마다 끝까지 반복된다. 이런 식으로 파일의 끝까지 재작성을 반복하면 문제 없다. 파일 크기는 끝에서 늘어나지, 중간이나 앞에서 늘어나지 않는다. 그러므로 변화시킬 때마다, 전체 파일을 재작성해야한다는데, 만약 쓰는 도중에 쓸 힘을 잃거나 소프트웨어적인 문제가 생기면 어떻게 될까? 간단한 문제는 아니다. 사고가 나기 직전까지의 상황을 그대로 유지하면서 아직 쓰여지지 않은 부분도 반영하고, 어떤 부분은 날라가 버리는 등 파괴 상태(corrupt state)가 되버린다. 당연히 이런 상황을 좋아하는 사람은 없다. 이런 "부분 완전" 에러는 큰 문제다. 예기치 못하게 버그가 생기고 퍼포먼스가 떨어지기 때문이다. 해결 방안은 여기서 시작한다. Programmer fixes it 문제를 고치는 일반적인 방법은 바로 "프로그래머에게 맡겨라"이다. 읽기/쓰기 접근을 위해 파일을 열거나 이전 파일을 덮어서 작성하는 대신, 프로그래머는 읽기-전용으로만 원래 파일을 열 수 있다. 저장할 때마다 새로운 파일이 생겨나고 여기에 작성하는 것이다. 파일 작성을 마치면 이전 파일의 이름을 고치고(보통 "to be deleted"로 바꾼다), 새로운 파일에 원래 파일의 이름을 준 다음, 이전 파일을 지운다. 이런 식으로 정렬을 했다면, 데이터를 잃을 가능성은 줄어들며, 설사 뭔가 잃더라도 새로운 버전과 이전 버전을 교환만 하면 되므로 전체 파일에는 영향을 끼치지 않는다. 정확한 경로를 알고 있다면 되짚어가서 찾아낼 수도 있을 것이다. 물론 좋은 방법이다. 프로그래밍도 잘만 하면 버그의 99%는 줄일 수 있다지만, 완벽하진 않다. 또한 수고가 많이 들기 때문에 누구나 이렇지는 못한다. 더구나, 이전 파일의 이름을 바꿨지만, 아직 새 파일의 이름을 다시 지정해주지 않는다거나, 아직 이전 파일을 지우지 않았다거나, 생각할 수 있는 실수의 가능성은 무한하다. 즉, 1%라도 버그는 존재할 수 있다. 앞의 경우, 데이터의 관계를 잃어버리기에, 찾아서 고쳐내기가 힘들어진다. 뒤의 경우는 드라이브상에 이전 파일이 남아있기 때문에 원하지 않는 파일(orphaned temp files)로 채워지기에, 고칠 수야 있지만 완벽할 수는 없다. 이럴 때는 "log"를 작성해서 고치는 방법이 있다. 로그가 남겨져있다면 무슨 일이 일어나더라도 어디를 고쳐야할 지 정확하게 알 수 있기 때문이다. 바로 이 방법을 저널링(혹은 로깅)이라고 하며, 보통 파일 시스템의 저널라이징의 의미가 쓰이지만, 다른 종류의 저널라이징에 대해서도 설명해보겠다. Journaled Files 새로 작성해야하는 경우는 모두 피하는 프로그램도 있다. 왜 모든 파일이 하나의 저널이 될 수는 없을까? 파일을 복잡한 구조로 유지하기보다는 파일이 작성되는 곳을 문서의 전체 구조로, 즉, 저널이라 로그로 하기 때문이다. 기본적으로 모든 명령은 디스크에 작성되며, 사실 이런 프로그램들은 "저장" 명령을 갖고 있지 않고 끊임없이 자동 저장된다. 어떻게보면 무한한 명령취소 가능 파일링 시스템이랄 수 있다. 파일을 열때, 이런 저널 파일을 읽거나 문서 전체가 빠르게 타이핑되고, 철자 실수나 수정은 다음에 이뤄지는 광경을 쳐다보는 느낌은 참 신기하다. 즉, 당신의 파일은 최종 결과물의 구조가 아니라, 최종 결과물에 이르는 이벤트의 시퀀스인 셈이다. 이런 시스템은 파일을 덮어서 작성하는 것이 아니라 그저 계속 추가하는 것이기 때문에 가벼우며, 그렇기 때문에 어떤 작업물이건 잃을 수 없다. 시간에 걸쳐 작성되기 때문에, 잃었으리라 여기는 건 가장 최근에 작성한 명령/키스트록일 경우가 많다. 가장 최근 것이라면 어떻게든 기억하고 있을 때도 많다. 하지만,누구나 생각할 수 있는 단점이 있다. 저널은 쓸모없는 것까지 전부다 추적한다. 스무 장을 친 다음에 10 장씩 나누고, 몇 번 재구성한다고 가정해보자. 보통의 파일에서 최종 결과물은 10장 크기이다. 하지만 저널이 개입될 경우 30~40장에 이르르며, 읽을 때마다 모든 커맨드를 실행시킬 때까지 기다려야한다. 결코 효율적이지 못하다. 따라서 저장할 때 필요한 커맨드만 작성하는 혼합법도 있다. 저장하기 전에 똑같은 것을 서너번 편집한다면 마지막 것만 남겨서 일을 효율적으로 처리할 수 있다.(마지막 것만 중요하기 때문이다) 하지만 풀 저널링(Full Journaling)은 앞의 개념이다. 사실 저널링 파일 시스템을 얘기할 때는 보통 풀 저널링을 얘기하지는 않는다. Hybrid Filing 오픈독(OpenDoc)은 깔끔한 혼합 시스템, 혹은 백지(컨셉트 도큐먼트) 상에 작성하는 식이었다. 기본적으로 오픈독은 저장, 혹은 스냅숏을 찍을 때까지 끊임없이 저널을 작성한다. 저장되면 전체 버전, 혹은 파일의 스냅숏을 저장하며, 스냅숏은 전체 파일 취급을 받아 시퀀스 순서가 아닌 로직 순서대로 배열된다. 그래서 원래 파일이 스냅숏을 첨부하면, 저널은 삭제되고 다시 시작하는 식이다. 이제 각 파일은 실제로는 수많은 파일로 이뤄져있다. 각자 자신의 영역(fork)에 저장되기 때문이다. 포크화된 파일링 시스템에서는 각자 연결된 파일이 수없이 많이 존재한다. 따라서 파일을 드래그하면 여기에 관계된 모든 파일을 드래그하는 것이며, 이 파일은 각 포크가 sub-파일로 들어간 특수한 폴더처럼 보면 된다. 이렇게 파일의 이전 버전/스냅숏을 되돌아볼 수 있다는 것, 버전 컨트롤(version control)이 OpenDoc / Bento 기반 시스템의 강점이었다. 사실 예전 오퍼레이팅 시스템 중에 하나인 DEC의 VMS가 유사하지만 원시적인 버전 컨트롤을 채택했었고 이 기능은 상당수의 호평을 받았다. 오픈독의 버전 컨트롤은 훨씬 균형잡혀있었고 현대적이었다. 오픈독에서는 원하는 경우 이전 버전을 삭제하거나, 놔두는 등의 선택을 할 수 있었고, 선택한 명령에 대해 히스토리를 작성한다. 마지막 포크(저널)는 마지막 스냅숏과의 차이점만을 기록하기에 결코 커다랗지 않으며, 차이가 클 경우에는 스냅숏을 저장하면 된다. 각 파일은 수많은 부분(포크)으로 나뉘어져있기 때문에 무슨 일이 일어나더라도 백업으로 다른 부분은 계속 존재한다. 즉, 저널화되면 모든 변화를 계속 저장(별도로 수동 저장이 아니다)하여서 무한한 수준의 명령 취소를 할 수 있다. 하지만 오픈독은 정치적인 이유로 죽고말았다. 오픈독과 함께 그 아이디어도 죽었지만, 좋은 아이디어는 결국 돌아오게 마련이다. 요즘 저널링 파일 시스템을 이야기하는 사람들 태반은 오픈독에 대해 듣지 못했거나, 오픈독이 어떤 식이었는지 모를 것이다. 그래서 다른 이야기들을 한다. Journaled Filing Systems 파일을 만들 때, 파일에 대해 영향을 끼치는 수많은 명령들도 조심해야한다. 파일을 복사하거나 이동, 이름짓기 등은 모두 파일에 영향을 끼친다. 이런 명령들은 전부 OS 책임이며, 대부분의 프로그래머들은 OS가 무엇을 할 지 숙지해놓아야한다. 유닉스 계열에서는 하이레벨은 무시하고 로우레벨만 이야기하는 성향이 있기 때문에, 이들이 얘기하는 저널 시스템은 프로그래머와 프로그램이 하는 저널링이 아니라 OS의 저널링(혹은 제일 낮은 로우레벨에서의 저널링)이다. 오퍼레이팅 시스템(파일링 시스템)이 파일을 복사한다거나 이동, 이름짓기를 시도하면, 파일에 변화가 생긴다. 이런 변화는 로우레벨 작성, 혹은 변화를 요구하기 때문에, 시스템 충돌은 이러한 시퀀스에서 생겨나고, 충돌에 의해 데이터를 잃게 된다. 보통, 유닉스(혹은 다른 OS들) 상에서는 부분적으로 고쳐낼 수 있는 부분이 많다. 가령 부팅할 때, fsck라는 유틸리티가 있다. Fsck는 기본적으로 디스크상의 모든 파일과 프라그먼트를 검색하고 어떤 부분이 비정상인 지를 확인한 다음에 고치거나, 회복할 수 없는 경우에는 지운다. 디스크가 크고 파일이 많다면 이 과정도 오래걸린다. 대부분의 오퍼레이팅 시스템은 비슷한 유틸리티를 갖고 있으며, 이걸 좀더 예쁘게 처리해주는 써드 파티 유틸리티도 많다. 그런데 파일링 시스템이 저널화되면, 데이터-손실 현상이 일어나기 전에 오퍼레이팅 시스템이 별도의 로그 파일이나 저널을 스스로 작성한다. 그에맞는 처리가 뒤이어 일어나고 최종적으로는 로그파일이 정리된다. 이때 시스템이 어느 때라도 충돌을 일으킨다면 전체 디스크를 스캐닝하기보다는 로그 파일을 조사해서 변화한 지점을 알아내고 재처리할 수 있다. 기존의 방법보다 훨씬 빠르며, 데이터 손실도 거의 없다. 하지만 대가가 없진 않다. 뭔가 변할 때마다 로그를 우선 작성해야하기 때문이다. 사소한 변화도 로그를 업데이트하기 때문에 로그는 디스크와 어느 때라도 싱크가 이뤄줘야한다. 따라서 대부분의 저널 시스템은 비 저널 시스템보다 느리다. 또한 알 수 있다시피 파일링 시스템이 제일 하부 레벨에서까지 저널화된다고 애플리케이션(프로그램)도 안전하게 저널화한다는 뜻은 아니다. 각 애플리케이션들에 대해서는 프로그래머들이 저널화시켜야한다. Conclusion 저널링이나 로그에는 이야기거리가 무척 많음을 알았을 것이다. 저널링에는 많은 단계, 수많은 종류가 있으며, 애플이 MacOS X의 저널화에 대해 논의하고 있다는 소식이 필자로서는 무척 기쁘다. 물론 속도나 신뢰성에 따라 사용할 수도 사용하지 않을 수도 있다. 사실 OS 때문에 일어나는 데이터 손실은 이미 무척 낮아졌다. 오히려 애플리케이션이 걱정이다. 유닉스 버전의 저널링은 그 문제의 일부만 해결할 뿐이다. 필자는 하이-레벨 저널링과 버전 컨트롤을 어느정도 수준으로 프로그래머에게 돌리는 가에 관심이 있다. 물론 여기에도 여러 단계가 있음은 물론이다. 언제인가는 이 영역도 모두 바뀌어서, 하이레벨로 저널을 조사할 날이 오리라 희망한다. 안정성과 보안의 진전은 좋은 소식임에 틀림없다. http://www.igeek.com/browse.php?id=1093 __________________ FAQ casaubon 님께서 2003-11-26 05:50 PM 에 수정하셨습니다..

2003-11-26, 04:03 AM	#2
sjahn Senior Member Registered: Jul 2002 My Mac: G4 Cube 450, SoundSticks Posts: 371 오프라인	저널링에 대한 좋은 글이군요. 요즘 Mac OS X 10.3 팬서에 저널닝을 온,오프할수 있는 기능이 있어 궁금했는데, 그 내용에 대한 좋은 글이었습니다. 감사합니다. 지금 이것을 적용시킬지 말아야 할지 논의가 많은데 한번 테스트 해야 겠습니디다. __________________ 어깨는 들썩들썩, 꼬리는 살랑살랑 ichat : sjahn http://www.cyworld.com/sjahn1999 http://homepage.mac.com/sjahn

2003-11-26, 05:50 PM	#3
casaubon Moderator Registered: Sep 2001 My Mac: MacBook Air Posts: 2,137 오프라인	저널링에 대한 해석 부분에 중요한 내용이 누락되어 있었습니다. 바로 덮어쓰기에 대한 '반복' 부분이 굉장히 모호하게 되어 있었는 데요. ilovja 님의 지적덕분에 다시 깔끔하게 할 수 있었습니다. 고친 부분은 전과 마찬가지로 위와 같이 코드 처리 하였습니다. ilovja 님, 정말 감사드립니다. ^^; 어차피 모두 같이 보는 글이니만큼 최대한 올바르게 번역해야 합니다. 원문과 비교해서 보시는 분들은 주저말고 이게 아닌갑다 싶으시면, 댓글을 쓰시거나 쪽지를 보내주세요. 절대로 미안해 하실 일이 아닙니다. 제 눈의 대들보는 제가 못 보죠. 제 잘못을 고치려면 여러분의 도움이 필요합니다. __________________ FAQ

2003-11-26, 06:05 PM	#4
endovert Elite Member Registered: Jan 2003 My Mac: iBook 12" G3 900MHz - iMac 24" - MacBook Pro Posts: 1,646 오프라인	항상 좋은글 감사드립니다~ 그나저나 OpenDoc은 부활 안할런지 모르겠네요.... ActiveX를 대적할만한 뭔가가 있어얄텐데 말이죠.... OpenDoc에 저널링까지 포함돼 있었다는건 또 처음 알았네요~ 역시 OpenDoc~! 시대를 넘 앞서나갔어~~ __________________ To the End of the Earth... To the Lost Paradise...

글타래 옵션
프린트 메일