File-System Implementation

(1)

File System

(Implementation)

– Ch. 11

SISTIM OPERASI

(Operating System)

IKI-20230

Johny Moningka

(moningka@cs.ui.ac.id)

Fakultas Ilmu Komputer Universitas Indonesia Semester 2000/2001 File System JM-2000/v1.1/2

File-System Implementation

n

File-System Structure

n

Allocation Methods

n

Free-Space Management

(2)

File System JM-2000/v1.1/3

Review

n

Storage management (server):

n

Performance management (secara global):

• File sharing (server), potensi user akses yang sangat banyak. • Bottleneck pada I/O dari server => dedicated komputer untuk

disk storage => management mudah (centralized). • Teknologi: SAN (storage area network).

n

Capacity management:

• Strategi untuk mendukung memori hirarkis: kapan data harus di migrasi dari storage cost/byte mahal ke storage cost/byte lebih murah => Backup dan pengarsipan.

• Quota dan alokasi disk high speed untuk aplikasi penting.

n

Availability:

• Termasuk solusi RAID, network restore etc. • Bad blocks (disk)? Hardware or software recovery.

File-System Structure

n

File structure

n

Isi file: kumpulan byte yang berhubungan dengan

informasi.

n

Logical storage unit: urutan byte, dengan akses

address secara logical (offset:1 s/d sizeof file).

n

Bagaimana layout file => disk (sektor)

n

Data file disimpan dalam blok (kelipatan besarnya

sector).

• Logical address disk: urutan blok data.

n

Implementasi:

• Mengurangi overhead mendapatkan data (seek, rotation). • Manajemen blok yang bebas (free list).

(3)

Disk Management

n

Alokasi struktur blok disk:

n

Contiguous allocation

n

Linked allocation.

n

Indexed allocation.

n

Manajemen free list dari blok storage.

n

Manajemen volume, partisi disk.

Workloads

n

Bagaimana cara user menggunakan file?

n

Sequential access: data besar dan berurut.

n

Random access: data kecil dan lokasi blok tidak

berurut.

n

Hal yang menjadi dasar design file structure:

n

Umumnya file ukurannya kecil (pengamatan).

n

Sebagian dari blok disk digunakan oleh file yang besar

(porsi terbesar).

n

Jadi perlu dukungan untuk kedua model akses : akses

random (file kecil yang banyak) dan sequential (file

yang besar dan aktifitas tinggi) => trade off yang sulit

dipenuhi.

(4)

Contiguous Allocation

n

Setiap file menempati “sekumpulan” blok yang

contiguous (sinambung) pada disk.

n

Umumnya max. besar file telah tetap (user menentukan).

n

Pro’s:

n Manajemen blok yang dialokasikan sederhana.

n Informasi awal lokasi nomor blok dan panjang blok yang dialokasikan.

n

Con’s:

n Space terbuang percuma, belum tentu sebesar data/isi file (dynamic storage-allocation problem).

n Sulit memperbesar (demand, grow) dari file.

Simple mechanism

n

Example: IBM OS/360

n When creating a file, make the user specify pre-specify its length and allocate all space at once

n File descriptor contents: location and size

n Pro: simple, fast access, both sequential and random.

n Masalah: fragementasi => perlu penggabungan blok yang kecil menjadi contiguous blok besar

file a (base=1,len=3) file b (base=5,len=2)

what happens if file c needs 2 blok???

(5)

Simple mechanism

n

“Extent-based”: allocate files like segmented memory

file a (base=1,len=3) file b (base=5,len=2)

what happens if

file c needs 2

sectors???

Linked files

n

Basically a linked list on disk.

n

Keep a linked list of all free blocks

n

pro: easy dynamic growth & sequential access, no

fragmentation

n

con?

n

Examples (sort-of): Alto, TOPS-10, DOS FAT

file a (base=1) file b (base=5)

how do you find

the last block in a?

Variably sized, flexibly laid out files

(6)

Linked Allocation

n

Setiap file terdiri dari “linked list” dari blok disk:

n Mekanisme pengurutan blok yang dialokasikan untuk suatu file. n Blok yang dialokasikan dapat tersebar (scattered):

• Tidak perlu “fixed allocation” => menjawab dynamic allocation problem.

n File descriptor: a pointer to file’s first block

n Setiap blok menyimpan pointer yang menunjuk ke blok yang berikut.

Data

block =

pointer ke alokasi blok berikutnya

Linked List

Allocate as needed, link together;

e.g., file starts at block 9

Bagaimana melakukan random access? “Follow the link”, overhead besar (read blok disk; linked list) => banyak seek)

(7)

Example: DOS FS (simplified)

n

Performance: Link dikumpulkan pada fixed-sized “file

allocation table” (FAT) => tidak disebarkan pada setiap

blok.

n FAT cukup kecil dapat disimpan “cache” disk => akses tanpa melakukan seek.

file a

6 4 3

free

eof

1 eof

3 eof

4 ...

file b

2 1

FAT (16-bit entries)

a: 6

b: 2

Directory (5) 0

1

2

3

4

5

6

FAT discussion

n

Entry size = 16 bits nomor blok

n

Berapa maksimum ukuran FAT?

n

Jika 512 byte per blok,

what’s the maximum size of FS yang dapat dikenal?

n

Solusi sederhana: memperbesar ukuran blok.

n

Reliability: how to protect against errors?

n

FAT menempati satu area tertentu (contiguous sector)

=> what happen if corrupt?

n

Buat duplikat FAT on disk.

n

Bootstrapping: where is root directory?

n

Fixed location on disk:

FAT (opt) FAT root dir …

64k* 2 = 128K 64K*.5k = 32M FS

(8)

Indexed files

n

Kumpulkan pointer blok ke dalam satu “indexed block”.

n Implementasi: array pointer => max. ukuran file yang dapat

ditampung oleh array tersebut.

n Create file: alokasikan blok pertama untuk menyimpan array pointer, blok akan diberikan “on demand” oleh user (dynamic).

n Pro: mendukung sequential access dan random (read the first block, and scan the array pointer).

file a file b

(9)

Indexed files

n

Issues (sama seperti masalah page table besar)

n

Ukuran file kecil = lots of unused entries

n

Mendukung file besar? table array menempati banyak

blok yang contiguous.

2^32 file size

2^20 entries!

4K blocks

idle

4K block size, 4GB file = 1M entries (4MB!)

Multi-leve indexed

idle

Pembagian struktur index hirarkis:

region dengan index array (1

st

_{level), menunjuk}

ke index array (2

nd

_{level) dst.}

(10)

Indexed Allocation – Mapping

M

o u t e r- index

index table file

Example UNIX: inode

Untuk file kecil: 1 blok data Size: 4 Kbytes/blok

Ukuran inode: 100 bytes Overhead: 2,5%

(11)

Ptr 1

ptr 2

…

ptr 128

Multi-level indexed files

n

File descriptor (inode) = 14 block pointers

Ptr 1

ptr 2

ptr 3

ptr 4

...

ptr 13

ptr 14

stuff

data blocks

Ptr 1

ptr 2

…

ptr 128

Indirect block

Double indirect block

Indirect blks

UNIX: inodes

n

Inodes disimpan pada array (fixed)

n Besarnya array inode ditentuk saat disk di format (initialized) dan menempati lokasi tertentu (awal atau tersebar).

n Array inode tidak dapat diubah (kecuali melakuk reformat).

n File system menyimpan (direktori) index yang menunjuk ke i-node (OS Unix menyebut i-number).

n Saat file dibuka, maka I-number diambil dari direktori dan i-node disimpan ke memori (bagian dari referensi PCB proses tsb).

(12)

Example: Unix file system

n

Want to modify byte 4 in /a/b.c:

n

“read” root

(blk 10)

n

lookup a (blk 12); “read”

n

lookup

inode

for b.c (13); “read”

n

Gunakan inode mencari byte 4 (blksize = 4KB, so

offset = 0 gives blk 14); “read”

Root directory

. : 10 : dir a: 12: dir

. :12 dir .. :10:dir b.c :13:inode

refcnt=1

int main() { …

14 0 … 0

Block: OS view

n

Berapa besar blok data suatu file system?

n

Sistim lama (disk kecil): 512 Bytes => saat ini 4 KB.

n

Contoh: Unix (V7) => Unix 4.2 BSD (Berkeley)

• Analisa performance response time FS, meningkat 4 x lebih cepat (sequential access).

• Why? Makin kecil ukuran block => makin banyak blok yang yang harus ditransfer atau makin banyak I/O operation yang harus dilakukan.

• Setiap I/O operation: faktor waktu latency sampai data dapat ditransfer.

n

Mengapa tidak membuat blok menjadi sangat besar?

• Internal fragmentation (ingat: umumnya ukuran file kecil): waste of space.

(13)

Free-Space Management

n

Bit vector (n blocks)

… 0 1 2 n - 1 bit[i] = 678 0 ⇒block[i] free 1 ⇒block[i] occupied

n

Free list: model pembagian daftar blok yang

bebas dalam linked list.

n

Pointer (next) disimpan pada blok yang

bebas.

n

Umumnya tidak satu linked list tunggal, tapi

di pilah dalam sekumpulan linked list.

Free-Space Management (Cont.)

n

Bit map requires extra space. Example:

block size = 2^12 bytes (4 K)

disk size = 2^30 bytes (1 gigabyte)

n = 2^30/2^12 = 2^18 bits (or 32K bytes)

n

Need to protect:

n

Pointer to free list

n

Bit map

• Must be kept on disk

• Copy in memory and disk may differ.

n

Solution (konsistensi check)

• Set bit[i] = 1 in disk. • Allocate block[i] • Set bit[i] = 1 in memory