Linking a human readable name to the file Putting the link in a directory 16

Linking a human readable name to the file putting the

This preview shows page 16 - 31 out of 60 pages.

Linking a human-readable name to the file Putting the link in a directory 16
Image of page 16
Info about file (stored in inode) struct stat { dev_t st_dev; /* ID of device containing file */ ino_t st_ino; /* inode number */ mode_t st_mode; /* protection */ nlink_t st_nlink; /* number of (hard) links */ uid_t st_uid; /* user ID of owner */ gid_t st_gid; /* group ID of owner */ dev_t st_rdev; /* device ID (if special file) */ off_t st_size; /* total size, in bytes */ blksize_t st_blksize; /* blocksize for filesystem I/O */ blkcnt_t st_blocks; /* number of blocks allocated */ time_t st_atime; /* last time file content was examined */ time_t st_mtime; /* last time file content was changed */ time_t st_ctime; /* last time inode was changed */ }; 17
Image of page 17
inode Stores metadata/attributes about the file Also stores locations of blocks holding the content of the file 18
Image of page 18
Example a.txt abc def abc def abc def 19 Block size # of blocks allocated Device id Inode # User id Group id # of (hard) links Access permission
Image of page 19
Working with directories Create: mkdir() system call Used to implement command, e.g., mkdir xyz Read: opendir(), readdir(), closedir() ls xyz Delete: rmdir() 20
Image of page 20
Roadmap Files and directories CRUD operations Implementation Data structures: how to organize the blocks Access methods: map system calls to operations on data structures 21
Image of page 21
Organization of blocks Array-based Disk consists of a list of blocks We will assume this Tree-based, e.g., SGI XFS Blocks are organized into variable-length extents Use B+-tree to quickly find free extents 22
Image of page 22
Blocks Consider a disk with 64 blocks 4KB/block 512B/sector (we assume this in this lecture) So there are 2 12 /2 9 = 2 3 = 8 sectors/block Capacity of disk = 64 * 4KB = 256KB 23
Image of page 23
Data region 56 blocks used to store data (files) Blocks # 8 – 63 24
Image of page 24
Metadata For each file, file system keeps track of Location of the blocks that comprise the file Size of the file Owner and access rights Access and modify times Etc. (see the stat struct a couple of slides back…) These metadata are stored in an inode (index node) 25
Image of page 25
inodes Index nodes Stored in blocks #3 -- #7 (i.e., 5 blocks) Together they are called inode table 26
Image of page 26
How many inodes are there? 256 bytes/inode 5 blocks, 4KB/block => 16 inodes/block (4K/256 = 2 12 /2 8 ) => 5 blocks, 5 * 16 = 80 inodes => File system can store at most 80 files 27
Image of page 27
Free space management using bitmaps Bitmap: a vector of bits 0 for free (inode/block), 1 for in-use Inode bitmap (imap) keep track of which inodes in the inode table are available Data bitmap (dmap) Keep track of which blocks in data region are available 28
Image of page 28
Bitmaps Each bitmap is stored in a block Block "i": keep track of 80 inodes (could track 32K) Block "d": keep track of the 56 data blocks 29
Image of page 29
Superblock Track where i/d blocks and inode table are E.g., inode table starts at block 3; there are 80 inodes and 56 data blocks, etc.
Image of page 30
Image of page 31

You've reached the end of your free preview.

Want to read all 60 pages?

  • Fall '14

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

Stuck? We have tutors online 24/7 who can help you get unstuck.
A+ icon
Ask Expert Tutors You can ask You can ask You can ask (will expire )
Answers in as fast as 15 minutes