Building a f ile syst em To build a f ile syst em f rom an array of - PDF document

Building a f ile syst em � To build a f ile syst em f rom an array of disk 12: FFS,LFS and ot her f ile sect ors we have t o decide t hings like syst ems � Must f iles be allocat ed cont iguously? � I f not how will be f ind t he pieces? Last Modif ied: � What inf or mat ion is st or ed about each f ile in 6/ 9/ 2004 12:17:20 PM t he dir ect or y? � Where do we put new f iles t hat are creat ed? � What do we do when f iles gr ow or shr ink? � How do we r ecover t he FS af t er a cr ash? -1 -2 Answers? How are t hey t he same? � We are going t o look at t wo dif f erent f ile � Bot h allow f iles t o be broken int o mult iple syst ems pieces � Bot h use f ixed sized blocks (f or t he most � Fast File Syst em (FFS) � Log-St r uct ur ed File Syst ems (LFS) part ) � Bot h use t he inode st ruct ure we discussed last t ime -3 -4 Fast File Syst em Managing Free Space � Fast ? Well f ast er t han or iginal UNI X f ile syst em � Br eak disk int o cylinder gr oups and t hen int o f ixed (1970’s) size pieces called blocks (commonly 4 KB) � Original syst em had poor disk bandwidt h ut ilizat ion � Each cylinder gr oup has a cer t ain number of blocks � Remember why t hat is a problem? Too many seeks � Cylinder group’s f ree list maps which blocks f ree and � BSD UNI X f olks r edesigned in mid 1980’s which t aken � Cylinder groups also st ore a copy of t he superblock which � I mproved disk ut ilizat ion by breaking f iles int o larger cont ains special boot st rapping inf ormat ion like t he pieces locat ion of t he root direct ory (replicat ed) � Made FFS aware of disk st ruct ure (cylinder groups) and � Cylinder groups also cont ain a f ixed number of I - nodes t ried t o keep relat ed t hings t oget her � Rest of blocks used t o st ore f ile/ direct ory dat a � Ot her semi- random improvement s like support f or long f ile names et c. -5 -6 1

I nodes in FFS Creat ing a new f ile � I n FFS, f ixed number of inodes at FS � I n t he pre-FFS UNI X f ile syst em f ormat t ime � Free list f or t he ent ire disk � When cr eat e f ile, pick an inode, will never move � St ar t ed out or der ed nicely such t hat if ask f or (so dir ect or y ent r y need not be updat ed) 3 f r ee blocks likely t o get 3 t oget her � Can r un out of inodes and not be able t o cr eat e � Randomized over t ime as f iles cr eat ed and f ile even t hough t her e is f r ee space delet ed such t hat pieces of a new f ile scat t er ed over t he disk � Also when cr eat e new f ile need a new inode t oo • All inodes at beginning of disk, f ar f rom t he dat a � When read t hrough a f ile likely t o be seeks bet ween each block – slow! -7 -8 FFS Cylinder Groups � Divide t he disk int o cylinder gr oups � To keep t hings t oget her must know when t o � Try t o put all blocks of f ile int o same cylinder group keep t hings apart � I nodes in each cylinder group so inodes near t heir f iles � Put lar ge f iles int o a dif f er ent cylinder gr oup � Try t o put f iles in t he same direct ory int o t he same � FFS reserves 10% of t he disk as f ree cylinder group � Big t hings f orced int o new cylinder group space � I s t his f undament ally a new appr oach? � To be able t o sor t t hings int o cylinder gr oups, � Not really… space wit hin a cylinder group get s t reat ed must have f r ee space in each cylinder gr oup j ust like whole disk was � 10% f r ee space avoids wor st allocat ion choice � Space in cylinder group get s f ragment ed et c as appr oach f ull (ex. One block in each cylinder � Basically sort f iles int o bins so reduce t he f requent long gr oup) seeks -9 -10 Ot her FFS I mprovement s Updat e I n P lace � Small or large blocks? � Bot h t he original UNI X FS and FFS were � Orig UNI X FS had small blocks (1 KB) updat e-i n-place � ¼ less ef f icient BW ut ilizat ion � When block X of a f ile is writ t en t hen � Lar ger blocks have pr oblems t oo f orever more, reads or writ es t o block X � For f iles < 4K , result s in int ernal f ragment at ion � FFS uses 4K blocks but allows f ragment s wit hin a block go t o t hat locat ion unt il f ile delet ed or � Last < 4K of a f ile can be in f ragment s t runcat ed � Exact ly 4K? � As t hings get f ragment ed need � FFS allows FS t o be paramet erized t o t he disk and CPU charact erist ics “def ragment er” t o reorganize t hings � Anot her cool example: when laying out logically sequent ial blocks skip a f ew blocks in bet ween each t o allow f or CPU int errupt processing so don’t j ust miss t he blocks and f orce a whole rot at ion -11 -12 2

Anot her P roblem wit h Updat e- Fixed order in-place Poor cr ash r ecover y per f or mance � Solut ion: Specif y or der in which FS ops ar e done � Some oper at ions t ake mult iple disk r equest s so ar e � Example t o add a f ile impossible t o do at omically � Updat e f ree list st ruct ures t o show dat a block t aken � Ex. Writ e a new f ile (updat e direct ory, remove space � Writ e t he dat a block f rom f ree list , writ e inode and dat a blocks, et c.) � Updat e f ree list st ruct ures t o show an inode t ake � I f syst em cr ashes (lose power or sof t war e � Writ e t he inode f ailur e), t her e may be f ile oper at ions in pr ogr ess � Add ent ry t o t he direct ory � When syst em comes back up, may need t o f ind a � I f cr ash occur s, on r eboot scan disk looking f or f ix t hese half done oper at ions half done oper at ions � Wher e ar e t hey? � I nodes t hat are marked t aken but are not ref erred t o by � Could be anywhere? any direct ory � How can we rest ore consist ency t o t he f ile syst em? � Dat a blocks t hat are maked t aken but are not ref erred t o by any inode -13 -14 Writ e-Ahead Logging Fixed order (con’t) (J ournaling) � We’ve f ound a half done oper at ion now what ? � How can we solve pr oblem of r ecover y in � I f dat a blocks not point ed t o by any inode t hen release updat e in place syst ems? t hem � Borrow a t echnique f rom dat abases! � I f inode not point ed t o by any direct ory link int o Lost and Found � Logging or j our naling � Fsck and similar FS r ecover y pr ogr ams do t hese � Bef ore perf orm a f ile syst em operat ion like kinds of checks � P roblems can be anywhere wit h updat e in place so must cr eat e new f ile or move a f ile, make a not e scan t he whole FS!! in t he log � P roblems? � I f crash, can simply examine t he log t o f ind � Recovery t akes a long t ime! (Syst em shut down uncleanly..checking your FS.. For t he next 10 minut es!) int errupt ed operat ions � Even worse(?) normal operat ion t akes a long t ime because specif ic order = many small synchronous writ es = slow! � Don’t need t o examine t he whole disk -15 -16 P roblems wit h writ e-ahead Checkpoint s logging � Per iodically wr it e a checkpoint t o a well known � Do writ es t wice locat ion � Once t o log and once t o “real” dat a (st ill � Checkpoint est ablishes a consist ent point in t he organized like FFS) f ile syst em � Checkpoint also cont ains point er t o t ail of t he log � Surprisingly can be more ef f icient t han (changes since checkpoint wr it t en) updat e-i n-place! � On r ecover y st ar t at checkpoint and t hen “r oll � Bat ched t o log and t hen r eplayed t o “r eal” in f or war d” t hr ough t he log r elaxed or der (elevat or scheduling on t he disk) � Checkpoint point s t o locat ion syst em will use f or f ir st log wr it e af t er checkpoint , t hen each log wr it e has point er t o next locat ion t o be used � Event ually go t o next locat ion and f ind it empt y or invalid � When wr it e a checkpoint can discar d ear lier por t ions of t he log -17 -18 3