I will discuss mid-term in the first half of the class Disk performance+reliability Background platter track (concentric) [sector] cylinder block. the basic unit of data in FS. Data always transferred, written and read in blocks! disk time: spin-up, seek-time, rotational delay, transfer time [RPM (revolutions per minutes)] Goal1: decrease seek-time [how? locality] Goal2: decrease rotional-delay ============= UFS background the main data-structure is unchanged buffer cache in memory on disk: super-block (including a pointer to the free-list) inode, indirect blocks data block Prob11: layout: 4MB inodes; followed by 146 M - inode far from data - inodes from the same direc not together - reliability concern - have one global free list (not per-cynlindar group) as a result, no locality after some time in the newer version, still locality even after some time when the free-list may have become random * old perfomance degrade with time (not that much with fullness) * new relates to fullness Prob2: parameter: 512B data block [reliability super block replication not put all i-nodes on the first platter rename] performance change 1:block-size 4096 + fragment fragment at least 512B frag. addressable! 2/4/8 frag. bit-map is at frag. level allocation's block selection: the last can use frag, ok to share w/ others or split a new free block, (new block only allocated when write occurs and needs), when you already have multiple fragments and need more, the old fragments will be COPIED to avoid multiple fragmented block in one file [Q: Why? i-node block indexing is harder] implication: write whole block size is faster (avoid copying) impact of fragment: - larger bit-map size + better space utilization - disk cannot be completely full (need free space reserve; you might have free fragment, but you will need free block!) + keep the good `relatively small space needed for indexing' Q: why allocating block in new FS is slower? Change 2: Layout princp. 1: locality (within one cylindar group) [decrease seek time][based on locality!] directory, i-node, data block * when new a directory, put it to the cyn. group with more than av. free i-node * put i-nodes of files in one directory in one cyn. group -- next free strategy [first-fit always allocate the 1st slot they find on the free-list to assign; the next-fit always starts the searching from where the last search left off] * data-block of a file (concern: if a file is too big, it will affect other files that are already inside its cynlindar group. Note: you didn't know how many data blocks you WILL have!) -- solution: spin-off to a new cyn. group (greater than av. free blocks) @ 48K, every 1M -- rotaional optimal [a vector, 8 rotation positions on disk] local-strategy: if global has inaccurate information and request a full block, put it to next block that is rotationally closest princp. 2: decrease rotational delay functionality improvement file locking (flock, still advisory, fcntl) symbolic link (advantage over hard link, disadvantage? (easily goes out of date)) rename originally unlink(to); link(from, to); unlink(from) basically you write the to's directory block twice and than write from's dir block the new one merge the 1st two operations to make sure that from is still there! lesson: learn your workload!! for reliability concern: FFS requires most write to be synchronous execute fsck (file system check) for crash recovery