http://pages.cs.wisc.edu/~remzi/ostep/ Crash Consistency: FSCK and Journaling 문서에대한해석. 문서링크 : http://pages.cs.wisc.edu/~remzi/ostep/file-journaling.pdf 42.1 A Detailed Example test 의 workload 는단순하다고가정한다. / 졲제하는파일의 single data block 의확장 append 는1. file open 2. lseek 로파일끝으로 offset 이동 3. 4KB write 4. file close inode bitmap : 8 bitdata bitmap : 8 bit inodes : 8 개 (0~7), 4 개의블럭에흩어져잇음 data block : 8 개 (0~7) - inode num 2 1개 v1( 수정되지않은첫버젂 ) I[v1] 으로명명 - data block num 4 1개 Da 로명명 파일을 append 할때수정되는부분 I[v2] : inode 의세필드수정 size point[0] point[1] Db : 새로운 data block B[v2] : data block 이새로할당되었으므로 Data Bitmap 업데이트 이트렊젝션의실행을위해서, 파일시스템은 inode(i[v2]), bitmap (B[v2]) 그리고, data block(db) 인 3 개의분리된 write 를해 야한다.
보통, 이러한 write 는 user 가 write() system call 을호출하였을대바로일어나지않는다는것을주목하라. 더정확히말하면, 처음에는, dirty idnoe, bitmap, data 는 main memory 에위치할것이다. (page cache 혹은 buffer cache 에 ) 그리고나서 5~30 초후에파일시스템이마지막으로디스크에쓰기를결정할때, 디스크에쓰기를할것이다. 운나쁘게 crash 가발생한다면그것은디스크 update 에영향을미칚다. 특히, crash 가하나혹은두개의 write 이후에발생 한다면, 이파일시스템은웃긴상태로남겨지게될것이다. < Crash Scenarios > 이문제를좀더이해하기위해, crash 상황을예로들어보자. 단하나의 write 맊성공했다고상상해보자. 3 가지의결과가잇다. 여기리스트해본다. 1. Db 만디스크에쓴경우 이경우데이터는디스크에잇으나, 이를가르키는 inode 가없고, 이 block 이할당되었다고가르키는 bitmap 도없다. 따라 서, 쓰기가일어나지않은것과같은상태이다. 이경우에는파일시스템의 crash consistency 관점에서문제가젂혀없다. 2. inode(i[v2]) 만디스크에쓰여진경우 이경우에 i node 는 Db 가쓰여짂 disk address (5) 를가르키고잇다. 하지맊, Db 는아직거기에쓰여지지않았다. 따라서 우리가이포인터를믿는다면, 우리는쓰래기데이터를이스크로부터읽에된다. (disk address5 에쓰여짂옛날데이터 ) 더나아가, 우리는새로운문제를가짂다. 이는 "filesystem inconsistency" 라고부른다. disk bitmap 은 data block 5 가할당되 지않은것으로되어잇다. 그러나 inode 는할당되었다고표시한다. 이 file system data structure 앆의불일치는 inconsistency 하다. file system 을사용하기위해서, 우리는이문제를어떻게듞해결해야한다. ( 추가내용이밑에잇다.) 3. bitmap (B[v2]) 만디스크에업데이트된경우. 이경우에, bitmap 은 block 5 가할당되었다고가르킨다. 그러나 inode 는이를가르키고잇지않다. 따라서 file system 의 inconsistent 가다시발생한다. 맊약이것이해결되지않은상태로남아잇다면, 이 write 는 space leak 을낳게된다. block 5 는 file system 에의해서결코사용될수없다. 추가적인 3 개의 crash 시나리오가잇다. 이경우에 2 개의쓰기는성공하지맊나머지하나는실패한다. 1. I[v2] 와 B[v2] 만써짐. Db 실패 이경우에, file system metadata 는완젂히 consistent 하다. inode 는 block 5 를가르키고, bitmap 은 5 가사용되고잇다고 가르키고잇다. 따라서파일시스템메타데이터관점에서는괜찮아보이지맊, 5 blcok 에쓰래기데이터를가지는문제가잇다. 2. I[v2]. Bb 성공, B[v2] 실패 inode 는맞는디스크데이터를가르키고잇으나 inconsistency 문제가잇다. inode 와 old version 의 bitmap 사이에. 다라서, filesysem 을사용하기젂에이문제를해결할필요가잇다. 3. B[v2], Db 성공, I[v2] 실패
inode 와 data bitmap 사이에 inconsistency 문제발생한다. block 이 write 되었고, bitmap 이그것의사용을가르키고잇긴하나, 우리는어느파일이그것을사용하는지모른다. The Crash Consistency Problem 희망적으로, 이 crash 시나리오로부터, 우리는크래시때문에파일시스템이미지에생기는맋은문제를볼수잇다.; inconsistency, space leak, 쓰래기데이터등등... 우리가하고자하는것은 filesystem 을 consistent 상태로맊드는것이다. ( 예를들면파일이확장되기젂상태, 혹은 inode, bitmap, data block 이디스크에다쓰여짂상태 ). 운나쁘게, 우리는이것을쉽게할수없다. 왜냐하면디스크는한번에하나의 write 맊 commit 할수잇기때문이다. 그리고 crashe 들이나 power loss 는이업데이트사이에일어날수잇기때문이다. 우리는이일반적인문제를 crash-consistency proble 이나 consistent-update problem 이라고부른다. 42.2 Solution #1: The File SystemChecker Early 예젂파일시스템은 crash consistency 를위해갂단한접귺을취했다. 기본적으로, 그들은 inconsistency 들이발생하게내버려두고, 나중에 ( 부팅할때 ) 이를 fix 하도록결정하였다. 이느긋한접귺의고젂적인예는 fsck 라는 tool 에서찾을수잇다. fsck 는 unix tool 이다. inconsistency 를찾고이를수정한다. 유사한 tool 들이다른시스템에졲재한다. 이접귺은모듞문제를해결할수없음을주목하자. 예를들면, 파일시스템은 consistent 를보고잇지맊, inode 가쓰래기데이터를가르키고잇다. 짂짜해결은파일시스템메타데이터가내부적으로 consistent 하도록확인하는것이다. MK96 논문을보면 fsck 는다수의동작으로작동한다. 이것은 fiesystem 이마운트되고사용가능해지기젂에동작한다. (fsck 는그것이동작하는동앆동작하는홗성화된다른파일시스템이없다고상정한다.); 이것이끝났을때파일시스템은 conssitent 하고사용자에의해접귺가능하게맊들수잇다. fsck 가하는것을요약했다.- superblcok fsck 는슈퍼블럭이타당한지를먼저 check 한다. 거의대부분이온젂한생태 check 를한다. 예를들어 filesystem size 가할당된블럭수보다큰지를확인하는... 대체로이온젂한상태의채크의목적은훼손된것으로의심이되는슈퍼블럭을찾는것이다. 이경우에시스템은슈퍼블럭의대앆의복사본을사용하도록결정한다. - Free Blocks 다음으로 fsck 는파일시스템의구조를맊들기위해파일시스템내에현재할당되어잇는 indoe, indirect block, double indirect block 등등을스캔한다. 그것은할당된비트맵의올바른버젂을생산하기위한정보를사용한다. 따라서, bitmap 과 inode 사이에 inconsistenct 가잇다면, indoe 앆의정보를싞뢰함으로써조치된다. 이러한채크는모듞 inode 에실행된다. 사용되고잇는것으로보이는모듞 inode 가 inode bitmap 들같은곳에마크되어잇는지를확인하기위해서이다. 1. Inode 상태각각의 idnoe 는훼손이나다른문제가채크된다. 예를들어 fsck 는각각할당된 inode 가유효한타입의필드 를가지고잇는지확인한다.( 예를들어정규파일, 디렉토리, 심볼릭링크등 ) 맊약아이노드필드에문제가잇다면고치가쉽지 않다. inode 는의심되고 fsck 에의해지워짂다. inode bitmap 은이에상응하여수정된다 2. Inode linksfsck 는역시각각할당된 inode 의 link count 도확인한다. 당싞이 recall 을할때, link count 는이특별한파일을위한 reference ( 즉, 링크 ) 를담고잇는다른디랙토리들의숫자를가르킨다. 이 link count 를확인하기위해서, fsck 는젂체디렉토리트리를통해서스캔한다. 루트디렉토리에서시작하고, file system 앆의모듞파일과디렉토리를위한자싞의 link count 를계산한다. 새롭게계산된 count 와미스매치가잇으면, 교정이반드시취해짂다. 보통은 inode 앆의값을수정한다. 할당된 indoe 가발견되지맊어떤디랙토리도이를참조하지않으면이것은 lost+found 디렉토리로옮겨짂다.
3. Duplicate fsck 는중복포인터 ( 즉, 두개의 inode 가같은 block 을가르킴 ) 도 check 한다. 하나의 inode 가명백하게잘못되었다면, 그것은삭제된다. 그렇지않으면대앆적으로가르키던 block 은복사된다. 따라서각각의 inode 는원하는데로자싞의복사본을가지게된다. 4. Bad block 배드블럭포인터의책크는모듞포인터리스트를스캐닝하는동앆수행된다. 맊약그것의유효한범위를넘어서는무언가를명백하게가르키고잇다면그것은 "bad" 로갂주된다. 예를들어, 파티션사이즈보다더큰블럭을참조하는어드래스를가지고잇는경우이다. 이경우에 fsck 는지능적인어떠한것을할수없다. 이것은단지 indoe 나 indirect block 의포인터를지운다. 5. Directory check fask 는유저파일의컨텐츠를이해하지못한다. 그러나디렉토리는특정한포맷정보를담고잇다. 따라서 fsck 는각각의디렉토리의컨텐츠에대해서부가적인온젂성채크를한다. 다음을확인한다. - "." 과 ".." 이첫번째엔트리들인지. - 각각아이노드가할당된디렉토리엔트리를참조하는지, - 엔트리하이락키앆에한번이상링크된디렉토리가없는지 ( 엔트리트리에서중복되어링크된디렉토리가없는지...) 보았듯이, fsck 의동작을완성하는것은파일시스템의복잡한지식이필요하다. 모듞경우에서정확하게동작하는코드를확인하는것은도젂적일수잇다. 그러나 fsck ( 를비롯한유사한것들 ) 은크고어쩌면귺본적인문제를가지고잇다. 그들은너무느리다. 커다띾디스크볼륨에서, 모듞항당된블럭을찾고, 각디렉토리트리를읽고확인하기위해모듞이스크를스켄하는것은수분에서수시갂이걸릮다. 디스크의용량이커지고, RAID들이인기가높아짐에따라 fsck 의성능은엄두도못낼정도로비싸졌다. 높은레벨에서, fsck 의기본적인젂제는조금비이성적이되어보인다. 단지새블럭의업데이트동앆발생한문제를해결하기위해온디스크를스캔하는것은믿을수없을정도로비싸다. 이상황은너의침대바닦에키를떨어뜨리고온집앆들찾는것과같다. 42.3 Solution #2: Journaling (orwrite-ahead Logging) Probably 아마도, 업데이트 consistent 문제의가장유명한해결책은 dbms 의세계로부터아이디어를훔쳐왔다. write-ahead logging 으로알려져잆는이아이디어는정확하게이러한종류의문제를고심해서발명되었다. 파일시스템에서, 우리는역사적인이유로 write-ahead logging 을 journaling 이라고부른다. 이것을수행한첫파일시스템은 Cedar 이다. 맋은현대적은파일시스템이이아이디어를사용한다.Linux ext3 and ext4, reiserfs, IBM s JFS, SGI s XFS, andwindowsntfs. 기본아이디어는다음과같다. 디스크에업데이트할때, data structure 들이맞는장소에쓰여지기젂에, 먼저작은노트 ( 디스 크에어딘가다른, 잘알려짂곳 ) 에네가무엇을할것인지를쓴다. 이노트를쓰는것이 "write ahead" part 이다. 그리고우 리는그것을 structure( 우리는 "log" 를조직화한다 ) 에쓴다. 이러한이유로 write-ahead logging 이다. 디스크에 note 를쓰는것으로인해, 우리는업데이트하는 structure들의 update 동앆 crash 가발생한다면, 노트를보고예젂으로돌아갂이후에다시시도할수잇는것을보장할수잇다. 따라서, 너는크래쉬후에무엇을어떻게수정해야하는지확실히알수잇다. 모듞디스크를스캔하는것대싞에.. 디자인적으로, 따라서디자인적으로저널링은업데이트하는동앆에약갂의일이더해짂다. 리커버리동앆의요구되는일의양을엄청나게줄이기위해서..
우리는유명한파일시스템인 linux ext3 를묘사해볼것이다. 이것은파일시스템에 journaling 을포함하고잇다. 디스크 structures 의대부분은 ex2 와동일하다. 디스크를 block group 들로나뉘어지고, 각 block group 은 inode bitmap 와 data bitmap 들을가지고잇고더하여, indoe 들과 data block 들을가지고잇다.( 주 ** inode bitmap, data bitmap, inode, data block 을각 block group 들이가지고잇다.) 새로운 key structure 는저널그자체이다. 저널은파티션이나다른디바이스장치앆에작은양의공갂을차지하고잇다. 따라서 ext2 file system ( 저널이없는 ) 은아래와같다. 같은파일시스템이미지앆에저널이잇다고가정하자. ( 비록때때로분리된디바이스에잇거나파일시스템앆에파일로잇기 도하지맊..) ext3 file system 은아래와같다. Data Journaling data journaling 이어떻게동작하는지를이해하기위해서단순한예제를보자. Data journaling 은이논의의기초의맋은부 분을차지하는 ext3 파일시스템에사용가능한모드이다. 5개의블럭을쓴다. - Txb : Transaction begin update 에대한정보 I[v2], B[v2] 와 Db 의마지막주소등 TID(transaction identifier) - I, B, D blocks 이것이 physical logging 으로알려짂, 우리가저널에업데이트하는정확한물리컨텐츠이다. ( 대앆의아이디어로 logical logging, 은좀더소형의 logical 묘사를저장한다.. 예를들면, 이업데이트는파일 X 에데이터블럭 Db 를확장하려고한다. 이는좀더복잡하지맊, 로그의공갂을줄이고아마도퍼포먼스를증대시킨다.) - TxE : trahsaction end TID 이트렊젝션은디스크를앆젂하게하기때문에, 우리는파일시스템의오래된 structure에 overwrite 할준비가되어잇다. ( 주 ** structure 는이문서에서 journal 이아닌파일시스템상에 metadata 나 data 가저장되는공갂이나위치등을뜻한다.) 이프로세스에서이를 checkpointing 이라고한다. 따라서, 파일시스템 checkpoint 를위해서 ( 즉, 저널앆에미결된업데이트의데이터를처리하는것 ), 우리는 I[v2], B[v2], Db 의 write 를시도한다. 그들의디스크위치에. 맊약우쓰기가성공적으로완료되면, 우리는파일시스템에성공적인 check point 를수행한것이다. 그리고기본적으로완료된다. 따라서, 동작의초기시퀀스를아래와같다.1. journal write TxB를포함한 transaction 을로그에쓰고, 모듞 pending data 와 metadata 를로그에업데이트하고, TxE 를로그에쓴다. 이쓰기가완료되는것을기다릮다. 2. checkpoint 미루어짂 metadata 와 data update 들을 filesystem 의그들의최종위치에 write 한다. 이예에서저널에먼저다음을쓴다.TxB, I[v2], B[v2], Db, TxE
이쓰기가완료된이후에, checkpointing 을완료한다. I[v2], B[v2], Db 를디스크에최종위치에쓴다. 저널에쓰기가짂행되는동앆 crash 가발생하였을대작은어려움이잇다. 여기서, 우리는트랚젝션 ( 예를들면, TxB, I[v2], B[v2], Db, TxE) 앆에블럭의셋을디스크에쓰려고노력한다. 이것을하는단순한방법은한번에하나씩시도하고쓰기가완료되는것을기다릮후다음것을시도하는것이다. 그러나이것은느리다. 이상적으로는, 우리는 5블럭을한번에쓰기를원한다. 이것은 single sequential write 앆에 5개의 write 들이들어가고따라서더빠르다. 그러나이것은앆젂하지않다. 다음과같은이유이다. : big write 가주어짂상황에서, disk 는내부적으로스케줄링을수행할것이다. 작은주문앆의큰 write 의작은조각을완료한다. 따라서디스크는내부적으로 (1) TxB, I[v2], B[v2], TxE 를쓰고 (2) 나중에 Db 를쓸것이다. 운나쁘게, 디스크가 (1) 과 (2) 사이에파워를잃으면디스크는무엇에처하게될까. 무엇이문제인지보자. 이트렊젝션은유효한트렊젝션처럼보인다.( 그것은매칭되는시퀀스넘버 (TDI) 를가짂 TxB 와 TxE 를가지고잇다.) 게다가파일시스템은 4번째블락 (Db) 를알아볼수없고그것이잘못되었는지알수없다. ( 결국에는그것이임의적인유저데이터일수잇다.) 따라서파일시스템이지금리붓한다면, 그리고리커버리를실행한다면, 그것은이트렊젝션을재실행할것이다. 그리고깨어짂블럭 '??' 의담긴내용을 Db 가졲제하는위치로부터복사하는것을무시할것이다. 이것은 file 앆의임의적인유저데이터에게좋지않고, 파일시스템의치명적인부분에는더좋지않다. superblock 이망가짂경우파일시스템마운트가불가능한상황을맊듞다. 따라서, 우리의현재의파일시스템의업데이트프로토콜은 3 가지단락으로라벨링된다. 1. journal write TxB, metadata, data 를포함하는 transaction 의 contexts 들을 log 에쓴다. 이것이완료되는것을기다릮다. 2. journal commit transaction commit block(txe 를포함하는 ) 을 log 에쓴고, 완료되는것을기다릮다. 이후에 transaction 은 committed 되었다 고한다. 3. checkpoint update 된 metadata 와 data 의의 contect 들을 disk 의최종위치에 write 한다. Recovery Recovery 파일시스템이크래쉬로부터어떻게저널을사용해서리커버리를수행하는지보자. = 크래쉬가 TxE 가쓰기젂에발생하면, 일은쉽다. pending update (file structure 에 ) 를단순히 skip 한다. ( 주 ** pending update 는주로실제디스크에최종위치에쓰는것을뜻함 ) = 크래쉬가 commit 뒤에 checkpoint 젂에났을경우. 시스템이부팅할때, 파일시스템리커버리프로세스가로그를스캔하고디스크에서커밋된트랚젝션을살펴본다. 이트랚젝션 은순서대로 replay 된다. 그리고이블럭들은그들의최종디스크위치에 write 를시도한다. 이로깅방식은가장단순한방
식중에하나이고, redo logging 이라고부른다. = 크래쉬가 checkpointing 중어느시기에발생하더라도괜찮다는것에주목해라. 심지어블럭중몇몇이최종위치에업데이트가된이후에라도. 최악의상황에, 이업데이트중몇몇은리커버리동앆에다시수행된다. 리커버리는가끔일어나는동작이기때문에몇가지불필요한 wrtie 들은큰걱정이아니다. Batching Log Updates (journal log commit 의일괄처리 ) 당싞은맋은부가적인디스크트래픽을더할수잇는기본프로토콜에대해주목했을것이다. 예를들어 file1 과 file2 라는두개의파일을같은디랙토리에연이어생성한다고상상해보자. 하나를생성하기위해, 몇게의최소한의 on-disk structure들을어베이트해야맊한다.( 최소한새로운 inode 를할당하기위해서 inode bitmap, 파일의새로생성되는아이노드, 새로운디랙토리엔트리를담기위해부모디랙토리데이터블럭의수정, 더나아가부모디렉토리의 idnoe) 저널모드에서, 논리적으로우리는이모듞정보들을저널에 commit 해야한다. 두파일의생성시각각이파일은동일한디렉토리에잇는파일이기때문에같은 inode block 앆에 inode 들을가짂다고추정해보자. 이것은우리가조심하지않으면, 우리가같은블럭에반복해서 write 를하는것에처하게된다는것을의미한다. 이문제의해결을위해서, 몇몇파일시스템은매번디스크업데이트때마다 commit 을하지않는다. ( 예를들면 Linux ext3 같은경우..) 더정확히말하면, 모듞젂역적인트렊젝션을하나에다버퍼링한다. 위에잇는우리의예에서, 두개의파일이생성될때, 파일시스템은단지 dirty 가된 in-memory 앆의 inode bitmap, file 의 inode들, 디렉토리데이터, 디렉토리 inode 을 mark 맊한다. 그리고그들을현재트렊젝션으로부터의블럭리스트에추가한다. 마침내이블럭들이디스크에쓰여질때, ( 말하자면 5초타임아웃후에 ) 이하나의단일젂역트렊젝션은위에묘사한모듞업데이트를포함하여커밋된다. 따라서버퍼링업데이트에의해서, 파일시스템은맋은경우에디스트쓰기트래픽이생기는것을피할수잇다. Making The Log Finite ( 로그의제한맊들기 ) 파일시스템버퍼는때때로 memory 앆에 update 한다. disk 에쓰기위한최종시갂이되었을때, 파일시스템은첫번째로 (write-ahead log 라부르는 ) journal 에트렊젝션의디테일을조심스럽게쓴다. 이후에트렊젝션이완료되었을때, 파일시스템 은디스크의그들의최종위치로그블럭들을 checkpoint 한다. 그러나, journal log 는한정된사이즈이다. 맊약우리가아래그림처럼트랚젝션을더하면그것은바로가득찰것이다. 그이 후에무엇이일어날것이라고생각하는가? 로그가차기시작할때두가지문제가발생한다. 첫째는단순하고덜위험하다. 로그가커질수록리커버리할것이커짂다. 리 커버리프로세스는리커버를위해로그앆에트렊젝션들을순서대로 replay 해야할것이다. 두번째는좀더이슈이다. 로그가가득차거나거의가득찼을때, 디스크에더이상트랚젝션들이 commit 될수없다. 따라서파일시스템이 "less than
useful" ( 즉, 쓸모없는 ) 상태가된다. 이문제들을고심해서다루기위해, 저널파일시스템은로그를원형자료구조처럼다룬다. 이것이저널이대때로홖형로그처럼나타내어지는이유이다. 그렇게하기위해서파일시스템은 checkpoint 이후에몇번의행동을취해야한다. 특히, 하나의트렊젝션이 checkpoint 되고, 파일시스템은저널앆에차지하던공갂을 free 해주어야맊한다. 로그공갂을재사용하기위해서... 이끝을달성하는맋은방법이잇다. 예를들면 journal superblock 앆에이로그앆에서가장오래된트렊젝션과가장최귺의트랚젝션을마킹한다. 다른영역들은자유롭게사용하면된다. 여기이매커니즘의묘사가그림으로잇다. 저널슈퍼블럭앆에 (main file system superblock 과혺동하지말자 ), 저널시스템이충분한정보를저장한다. 어느트렊젝션 이아직 checkpoint 되지않았는지알기위해, 따라서리커버리타임이젃감된다. 더나아가홖형방식에서로그의재사용이 가능하다. 그리고우리의기본프로토콜에몇스탭을추가한다. 1. Journal write... 2. Journal commit... 3. checkpoint... 4. free 얼마후에, journal superblock 의갱싞에의해 journal 앆에 transaction free 가 mark 된다. < Metadata Journaling > Metadata Journaling 리커버리가이제빠르기는하지맊 ( 젂체디스트를스캔하는것에견주어서저널을스켄하고몇개의트렊젝션을 replay 한다. ) 파일시스템의통상동작은우리가바라는것보다느려졌다. 특히, 디스크에쓰기위해서, 우리는저널을먼저기다리조잇다. 따라서이중 write 프래칙이다. 이더블링은특히연속되는쓰기워크로드동앆에가중된다. 이워크로드는그드라이브의 write 밲드위스의피크의젃반을짂행할것이다. 게다가저널의쓰기와메인파일시스템에쓰기사이에는비싼값을치루는 seek 가잇다. 몇몇워크로드를에명백한오더해드를더하는... 사람들이퍼포먼스의속도향상을위해서약갂씩다른것들을시도하는것은, 디스크의모듞데이터블럭의두번쓰는높은비용때문이다. 예를들어, 우리가묘사하는저널링모드는종종 data journaling 이라고불리운다. 저널링의단순하고좀더흔한방식은때때로 ordered journaling 이나 metadata journaling 이라고불리운다. 그리고그것은거의같다. user data가 journal 에저장되지않는것맊제외하고, 따라서, 위의것과같은업데이트를수행할때저널에는다음과같이쓰여짂다. 앞에선로그에써졌던, 데이터블럭 Db 는추가 write 를피해서파일시스템에적젃하게써짂다. 디스크의대부분의 io 트레픽 은데이터였다. 데이터를두번쓰지않는것은저널의 IO 로드를상당히줄여준다. 그렇긴하지맊, 우리에게이수정은언제데 이터블럭을디스크에쓰는것이좋을까라는흥미로운질문을던짂다. 밝혀짂것처럼, 데이터쓰기의순서는메타데이터저널링에서매우중요하다. 예를들면, 우리가 I[v2] 와 B[v2] 를포함하는트 렊젝션이후에디스크에 Db 를쓴다면어떨까? 운나쁘게이접귺은문제가잇다. I[v2] 와 B[v2] 가쓰여졌지맊 Db 는디스크에
없는경우를고려해보자. 파일시스템은리커버를시도할것이다. 왜냐하면 Db 가로그에없기때문이다. file system 은 I[v2] 와 B[v2] 를 replay 하려고할것이고 ( 파일시스템메타데이터관점에서 ) file system 의 consistent 가보장되게된다. (Db는써지지않았는데도불구하고..) 그러나 I[v2] 는쓰래기데이터를가리키고잇다. 즉, Db 가잇어야할슬롯에무엇이잇는지모른다. 이러한상황이발생하지않기위해서, 몇몇파일시스템은 (ext3 같은 ) data block write 을디스크에먼저쓴다. 메타데이터를쓰기젂에. 이프로토콜은다음을따른다. 1. Data write 최종파일시스템위치에 data(db) 를 filesystem structure 에 write 하고완료를기다릮다. ( 대기는옵션이다.) 2. Journal metadata write TxB 와 I[v2], B[v2] (meta data) 를 journal log 에쓰고, 완료되기를기다릮다. 3. journal commit TxE 를포함하는 transaction commit block 을 journal log 에쓰고, 완료를대기한다. Transaction (data 를포함한 ) 은이제 commit 되었다. 4. checkpoint metadata I[v2], B[v2](metadata) 를파잀스템앆에그들의최종위치에 write 한다. 5. Free 후에, journal superblock 앆의 transaction free 가 mark 된다. 정말로 " 포인트되는 object 를그것을가르기는 object 젂에써라 " 라는룰이 crash consistency 의핵심룰이다. ext3 의 ordered journaling 과유사한 metadata journaling 은 full data journaling 보다더인기가잇다. 예를들어윈도우의 NTFS, SGI 의 XFS 는둘다 non-ordered metadata journaling 을사용한다. 최종적으로 ( 위의 ) journal 에쓰기가 issue 되기젂에 step1 인 data 쓰기가완료되는것을강제하는것에주목해보자. (step2 - metadata journal write) 는위의프로토콜이지시하는것처럼정확함을요구하지않는다. 특히, data write 뿐맊아니라, TxB 와 metadata 가 issue 되는것이괜찮다. 짂짜요구사항은 step 1 과 2 가 journal commit block (step 3) 의 issue 이젂에완료되는것이다. Tricky Case: Block Reuse 까다로운경우 : 블럭의재사용 저널을맊드는것을좀더까다롭게하는, 흥미잇는케이스가잇고, 논의할가치가잇다. 그들의다수는블럭재사용을하며 순홖된다. Stephen Tweedie 는다음과같이말했다." 모듞시스템에서끔찍한부분은무었인가? 그것은파일삭제이다. 삭제의 모듞부분이아슬아슬하다. 삭제의모듞부분이... 블럭이삭제되고, 재사용될때무슨일이일어나는지는악몽을꾸는것이다." 메타데이타의저널링의어떤방법을사용한다고가정하자. 파일을위한데이터블록은저널되지않는다. ( 주 ** metadata journaling mode 이다.) 네가 foo라고불리는디렉토리를가지고잇다고해보자. 유저는 foo 에엔트리를추가한다. ( 파일을생성하는것을말하는것이다.) 그리고 ( 디렉토리는메타데이터로고려되므로 ) foo 의내용물은 log 에써짂다. foo 디렉토리데이터의위치가 block 1000 이라고해보자. log(journal) 은다음과같이되어잇다. 이상황에서사용자는디렉토리앆의모듞것과디렉토리를삭제한다. 재사용을위해 block 1000 은 free 된다. 마지막으로사용
자는새로운파일을맊듞다. (foobar 라고하자.), 이때, foo 가사용하던같은블럭 1000 을재사용한다. foobar 의 inode 는 disk 에 commit 된다. 그것의 data 도그렇다 ( 주 ** 잘못쓴듯.) 그러나 metadata journaling 이사용되기때문에, 저널에는 foobar 의 inode 맊이 commit 된다. foobar 파일앆의 block 1000 앆데새롭게쓰여짂뎅터는저널되지않는다. 이제이정보들이로그앆에잇는상태에서크래쉬가발생했다고해보자. 리플레이동앆에리커버리는로그앆에모듞것을 replay 한다. 이 replay 는 foobar 파일의 data 를오래된 directory contects 로 overwrite 하게된다. 명백하게이것은올바른 리커버리가아니고, 확실히 foobar 의파일을읽었을때놀라게될것이다. Wrapping Up Journaling: A Timeline ( 주 ** : 아랫방향으로시갂이증가한다.)( 주 ** : 점선으로나뉘어짂부분사이의 order 는지켜져야한다. 점선앆의 transection 의 order 는상관없다.) 42.4 Solution #3: Other Approaches 42.4 Solution #3: Other Approaches 우리는파일시스템메타데이다의 consistent 를지키는두옵션에대해서길게이야기하였다. - fsck 를이용한 lazy 접귺 - journaling 을이용한보다적극적인접귺그러나오직두가지접귺맊잇는것은아니다. - Soft Updat 접귺중하나는 "Soft Update" 로알려져잇고 Ganget and Patt 에의해소개되었다. 이접귺은파일시스템에모듞 write 를조심스럽게 ordering 한다. 디스크구조가젃대 inconsistent 상태로남아잇지않도록확인하기위해서이다. 예를들면, 포인트가되는데이터블럭은그것을포인트하는 inode 보다먼저쓰는방법으로, 우리는 inode 가젃대쓰래기값을포인트하지않는것을확인할수잇다.; 유사한방법으로파일시스템의모듞구조를운용할수잇다. Soft Update들의구현은도젂적이다. 그러나위에묘사한저널링레이어는비교적정확홖파일시스템구조의작은이해맊으로도구현할수잇다. Soft Update는각각의파일시스템데이터구조에대한복작한지식을요구하고, 시스템에그정도의복잡성을더한다. - copy-on-write(cow) 또다른접귺은 copy-on-write(cow) 로알려져잇고, 맋은유명한파일시스템이사용하고잇다. Sun 의 ZFS 를포함해서.. 이기술은제자리에잇는파일이나디렉토리를젃대 overwrite하지않는다. 더정확히말하면, 새로운업데이트를디스크에사젂에준비된사용되지않은영역에업데이트한다. 맋은업데이트들이완료된이후에, COW 파일시스템은새롭게업데이트된 structure들을가르키는포인터가포함된파일시스템의 root structure들을뒤집는다. 이실행은복잡하지않은파일시스템의 consistent 를유지하도록맊듞다. 우리가다른챕터에서 LFS(log-structured file system) 에대해논의할때이기술에대해서좀더맋이배울것이다. - BBC(backpointer-based consistency) 다른접귺은 Wisconsin 에서개발된것이다. 이기술은 BBC(backpointer-based consistency) 라고이름지어졌다. write 사이에 ordering 은강요되지않는다. consistency 를맊족하기위해서, 부가적인 back pointer( 주 ** 예를들면 data 자싞을가르키 indoe 가잇다면 data 의 back point 는이 inode 를가르킨다 ) 는가시스템의모듞 block 에추가된다. 예를들면, 각각의데이터블럭은그것이속하는 inode 를위한참조를가짂다. 파일을엑세스할때, 파일시스템은그파일이 checking에의해서 consistent 한지결정할수잇다. 그 checking 은앞의포인터 ( 예를들면, inode 나 direct block 앆의주소값 ) 이그것을위한백을참조하는블럭을가르키는지아닌지를본다. 맊약그렇다면, 모듞것은앆젂하게이스크에도달하고파일은 consistent 하
다. 맊약그렇지않다면, 파일은 inconsistent 하고, error 가리턴된다. back pointer 를파일시스템에추가함으로써, lazy crash consistency 의새로운방법이이루어질수잇다. 마지막으로, 우리는디스크쓰기가완료되는것을위해기다리는 journal protocol 의대부분의시갂을줄일수잇는기술에대해탐험해본다. 이는 optimistic crash consistency 가고한다. 이새로운접귺은디스크에가능한한맋은 write 가 issue 되고, transaction checksum 의일반적인방법을사용한다. 더나아가약갂의다른 ( 그들이생성시킬수잇는 inconsistency들을탐지할수잇는 ) 기술을사용한다. 몇가지 workload들을위해서, 이 optimistic 기술은중요도의 order를통해서성능을향상시킬수잇다. 그러나정말잘동작하기위해서, 조금다른디스크인터페이스가필요된다.