10/23/2015.1 File System Architecture. 10/23/2015.2 / bin unixdev etc user jim mike x y z tty00...

04/20/23 . 1

File System Architecture

04/20/23 . 2

/

bin unix devetc user

jimmike

xy

z

tty00 tty01

File System architecture

04/20/23 . 3

File System Layout

Super block Inode list Data BlocksBoot block

Boot Block : first sector, contains bootstrap code to initialize the operating systemSuper Block : how many file it can store, where to find free spaceInode List : The list of inode in the file system. Each Inode may represent a file or a directory.

Data Blocks : The list of data blocks to carry information in the files.

04/20/23 . 4

disk

The Buffer Cache

1 2

3 4 1 3

read file blockMemory

write file block

04/20/23 . 5

buffer allocation algorithms

Buffer allocation algorithms

Getblk brelse bread breada bwrite

getblk: allocate buffer in memory.

brelse: release buffer.

bread: read disk block

breada: read block ahead.

bwrite: write a disk block

04/20/23 . 6

Structure Of the Buffer Pool

Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

Header (28)

data

Header (4)

data

Header (17)

data

Header (5)

data

Header (50)

data

Header (10)

data

Header (3)

data

Header (35)

data

04/20/23 . 7

Structure Of Buffer Header

Device num

Block num

status

Data area

Ptr to next buf on hash queue

Ptr to next buf on hash queue

Ptr to next buf on free list

Ptr to prev buf on free list

•Device num: specify the file system device num.

•Block num: specify the block num of data on file system.

04/20/23 . 8

Buffer status

•The buffer is currently locked, unlocked, busy, or free.•The buffer contains valid data.•Delayed-write: the kernel must write the buffer back to the disk before reassigning the buffer. •The kernel is currently reading or writing the contents to disk.•A process is waiting for the buffer to become free.

04/20/23 . 9

Buffer Functions

•getblk: allocate buffer for read or write.

•brelse: release buffer when it is not needed any more.

04/20/23 . 10

Free list of buffers

Free list header Header (1)

data

Header (2)

data

Header (n)

data

Free list header Header (2)

data

Header (n)

data

04/20/23 . 11

Buffer Allocation: Scenario 1

Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(4)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(3)

data

(99)

data

(35)

data

Freelist header

The kernel finds the block on its hash queue, and its buffer is free.

04/20/23 . 12


Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(4)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(3)

data

(99)

data

(35)

data

Freelist header

After buffer allocation using getblk

•The kernel will mark the buffer busy; no other process can access it and change its contents while it is busy.

•The kernel may read data from disk, or write data to disk.

04/20/23 . 13


Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(4)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(3)

data

(99)

data

(35)

data

Freelist header

The kernel cannot find the block on its hash queue, so it allocates a buffer from its freelist.

Search for block 18-not in cache

04/20/23 . 14


Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(4)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(18)

data

(99)

data

(35)

data

Freelist header

•The kernel remove the first block (# 3) from the freelist.•The kernel mark the buffer to be busy.•Remove it from the hash queue from it is currently resides•Reassign the device # and block # to the free block.•Place the buffer in the correct hash queue.•Use the buffer for read or write.

04/20/23 . 15


Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(4)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(3)

data

(99)

data

(35)

data

Freelist header

The kernel cannot find the block on its hash queue, and in attempting to allocate a buffer from the free list, finds a

buffer on the free list that is marked as delayed write. The kernel write the block to the disk and allocate another buffer.


Delayed write

Delayed write

04/20/23 . 16


Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(4)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(3)

data

(99)

data

(35)

data

Freelist header

•The kernel takes off block 3,5 from freelist.

•The kernel start asynchronous write for block 3,5.

delayed write

delayed write

04/20/23 . 17


Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(28)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(3)

data

(99)

data

(35)

data

Freelist header

•The kernel will allocate buffer 4, release it from the free list.

• Assign the device # and block # for the buffer.

•Place the buffer in the correct hash queue.

delayed write

delayed write

04/20/23 . 18


Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(28)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(3)

data

(99)

data

(35)

data

Freelist header

•The kernel will allocate buffer 4, release it from the free list.

• Assign the device # and block # (28) for the buffer.

•Place the buffer in the correct hash queue.

writing

writing

04/20/23 . 19


Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(28)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(3)

data

(99)

data

(35)

data

Freelist header

When the buffer writing is complete blocks 3,5 will be placed in the free list.

writing complete

Writing complete

04/20/23 . 20


Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(4)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(3)

data

(99)

data

(35)

data

Freelist header

The kernel search for block 18 not in cache and free list is empty. The process will go into sleep until another process executes brelse, release a buffer, and wake up processes

waiting for this event.


sleep

04/20/23 . 21


Block no 0 mod 4

Block no 1 mod 4

Block no 2 mod 4

Block no 3 mod 4

(28)

data

(64)

data

(4)

data

(17)

data

(97)

data

(5)

data

(98)

data

(10)

data

(50)

data

(3)

data

(99)

data

(35)

data

Freelist header

The kernel search for a block in cache, it finds the block but the block is busy. The process goes to sleep and waits until

the buffer is available

Search for block 99 block is busy

Delayed write

Delayed write

busy

04/20/23 . 22

Race Condition

Race condition for a free buffer

Process A

•Allocate buffer for block b,• mark buffer busy,• initiate I/O, •sleep until done

Process B

•Find block b in hash queue•Buffer locked, go to sleep.

•I/O done, wake up.•brelse(): wake up others

•Buffer contains block b•Lock the buffer

04/20/23 . 23

Race Condition

•Get buffer assigned to block b. • reassign the buffer.

Process A

•Allocate buffer for block b,• mark buffer busy,• initiate I/O, •sleep until done

Process B

•Find block b in hash queue•Buffer locked, go to sleep.

•I/O done, wake up.•brelse(): wake up others

•Buffer does not contains block b•Start search a gain

Process C

•Sleep waiting for a free buffer

1

2

43

5

6

Process could sleep and wake up when a buffer becomes free, only go to sleep again because another process got

control of buffer first.

04/20/23 . 24

getblk system call

getblk (block no)

while (buffer not found)

if (block in hash queue)

if (buffer busy) // scenario 5

sleep (event buffer becomes free)

continue

mark buffer busy // scenario 1

remove buffer from free list

return buffer

else // block not in hash queue

if (there are no buffer on free list) //scenario 4

sleep (event any buffer become free)

continue;

remove buffer from free list

If (buffer marked for delayed write) // scenario 3

asynchronous write buffer to disk

continue

Remove buffer from old hash queue // scenario 2

Put buffer onto new hash queue

Return buffer

04/20/23 . 25

brelse system call

brelse (locked buffer){

wakeup all procs waiting for any buffer to be freewakeup all procs waiting for this buffer to be freeif (buffer is valid and not old and buffer not old)

Enqueue buffer at the end of the free listelse Enqueue buffer at the beginning of free listunlock (buffer)

}

04/20/23 . 26

bwrite system call

bwrite (){

initialize disk write;if (I/O synchronous){

sleep (event I/O complete);release buffer (brelse)

}else if (buffer marked for delayed write) mark buffer to be put at head of free list

}

04/20/23 . 27

bread system call

bread (block no){

get buffer for block no(getblk);if (buffer data valid)

return buffer;initiate disk read;sleep (event disk read complete);return buffer;

}

04/20/23 . 28

breada system call

•When the process reads the file sequentially, two disk blocks are read.

•The process asks for another block to be read using breada.

•If the first block is not in cache, asynchronous read is issued.

•If the second block is not in cache , asynchronous read is issued.

•The process sleeps until the first block is read, and the buffer is returned.

•The process doesn’t wait for the second block to be read.

04/20/23 . 29

breada system callbreadaInput: file system block number for immediate read

file system block number for asynchronous read{

if (second block not in cache)get buffer for second block (getblk)initiate disk read;

If (first block not in cache) get buffer for first block (getblk)initiate disk readsleep (event first buffer contains valid data)return buffer

else // first block in cacheread first block (bread)return buffer

}

04/20/23 . 30

Advantage & Disadvantage of Buffer Cache

•Use of the buffer cache can reduce the amount of disk traffic, thereby increasing overall system throughputs and decreasing response time.

•The buffer algorithm help ensure system integrity, because they maintain a common, singe image of disk blocks contained in the cache.•Disk crash might leave the file system in an incorrect state due to delay-write.

04/20/23 . 31

Lower Level File System Algorithms

•iget : return the previously allocated inode, possibly reading it from the disk.

•Iput : release the inode.

•nami : converts a path name to inode, using iget, iput and bmap.

•alloc: allocate a free disk block for a file.

•free: free a disk block.

•bmap: map logical file byte offset to file system block

•ialloc : allocate an inode for a file.

•ifree: free inode of a file

namei

iget iput bmapalloc free ialloc ifree

Lower level file system algorithms

04/20/23 . 32

File System Data Structure

User File Descriptor File Table Inode Table

User File Descriptor: For each process. identify all opens file for specific process

File table: Shared between all processes in the system . Contains how many bytes read or written, access rights allowed for the file

Indo Table: access rights and file blocks location

04/20/23 . 33

Inode list

0 1 2 3 4 5 6 7 8 9

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Disk blocks-each 512 bytes

Inode 64 bytes-8 in block

Inode offset in block = ((inode#-1)%#of-inode-per-block) x inode-size

Block # = (inode# / #of-inode-per-block)

Inode loc = block# x block-size + inode offset in block

04/20/23 . 34

Inode Data Structure

Pointers to others in core

Reference count

Logical device number

Inode number

Status (locked etc)

Owner id

Group id

Type (regular file)

Access date

Modified date

Number of links

File size

Disk addresses

Pointers to others in core

Reference count

Logical Device number

Inode number

Status (locked etc)

Owner id

Group id

Type (regular file)

Access date

Modified date

Number of links

File size

Disk addresses

In core

On disk

04/20/23 . 35

Active Inode Hash table & Free list

inode inode inode

inode inode

inode inode inode

Free list

04/20/23 . 36

iget system call iget (){

While (not done){

if (inode in inode cache){

If (inode locked)sleep (until inode is unlocked );continue; //??

}If (inode in free list)

remove inode from free listincrement reference count by 1return inode

}If (no node in free list)

Return errorremove new inode from free listRemove inode from old hash queue, and place on new one;read inode from Disk (bread)increment inode reference count by 1}

}

04/20/23 . 37

iput system call

iput (){

lock inodeDecrement inode reference countIf (reference count == 0){

If (inode link count == 0){

Free disk blocks for file (function free)Set type to 0Free inode (function ifree)

}If (file is accessed or modified or inode modified)

Update disk inodeput inode in free list

}unlock inode

}

04/20/23 . 38

Allocation of contagious blocks for file

File A File B File C

40 50 60 70

File A free File C

40 50 60 70

File B

85

Inode A

•Simple inode structure, point to the first and last location.

•Difficult to expand file if no space is available.

•Inefficient to expand file (copy file to new location).

•Fragmentation (garbage collection required).

04/20/23 . 39

Block File Allocation-inode fixed size

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

2 5 4 6 161 3 12 8 15 17 18 19 20 10

•No fragmentation problem.

•Since the inode is fixed, it is difficult to increase file size

04/20/23 . 40

Block size selection

Decreasing block size will decrease block fragmentation

Increasing block size will decrease file size for fixed size inode

Difficult to find a point which minimize fragmentation and maximize file size

04/20/23 . 41

Minimize fragmentation & Varying the file size

Direct 0

Direct 1

Direct 2

Direct 4

Direct 4

Direct 5

Direct 6

Direct 7

Direct 8

Direct 9Single indirection

Double indirection

Triple indirection

04/20/23 . 42

Block Layout of a sample file

Assume the block size = 1K

Block number is addressable by 32 bits

Block numbers per each block = 1024/32 = 32 block numbers

32

04/20/23 . 43


331

4096 0

228 1

45432 2

0 3

0 4

11111 5

0 6

101 7

367 8

0 9

428 10

9156 11

824 12

3333

Block 4096

Block 228

Block 9156Block 331

Block 3333

Block 367

0

04/20/23 . 44


Maximum file size-1K Bytes per block10 direct blocks with 1K bytes each 10K bytes

1 indirect blocks with 32 direct blocks 32K bytes

1 double indirect blocks with 32 indirect blocks 1024K bytes

1 triple indirect blocks with 32 double indirect blocks 32M BytesProcess wants to access byte offset 9000

Block # = (9000/1024) = 8 starting from 0 (block # 367)

Offset within block = 9000- 8*1024 = 808th byte from block # 367

Process wants to access byte offset 45000

First byte accessed by double indirect block = 32K + 10K = 43*1024=44032

Offset within block = 45000-44032 = 969 of the double indirect block

Byte number 45000 is in 0th single indirect block-block # 331

Byte number 969 is in the 0th (969/1024)direct block – block # 3333

04/20/23 . 45

bmap system call

bmap () // map logical offset into physical block #{

if (offset <=10 K) indirection level = 0else if (offset > 10K & <= 256K) indirection level = 1else if (offset>256K & <= 64M) indirection level = 2else if (offset > 64M) indirection level = 3for ( l=1; l < indirection level; l++){

calculate indirect block # from file offsetread indirect block using breadrelease an old indirect block using brelse

}calculate direct block #return (block #)

}

04/20/23 . 46

Directories structure

Byte offset Inode number

2 bytes

File name

14 bytes

0 83 .

16 2 .. (parent)

32 1798 init

48 85 fsk

64 108 mount

80 1544 passwd

96 2344 mknod

112 567 mkfs

04/20/23 . 47

namei system call

namei () // convert path name to indoe{

If (path name start from root) // /user/cse8343/jim working node = root node (alg iget)

else // ./cse8343/jimworking node = current directory inode (alg iget)

while (there is more path name){

read next path name component from inputverify that working inode is of directory and permission is okread directory working inode by using bmap bread and brelseif (component matches an entry in directory (working inode){

get inode number for match componentreleases working inode (alg iput)working inode = inode matched component (alg iget)

}else // component not in directory{

return no node}

}return working inode

}

04/20/23 . 48

Super Block Fields

•The size of the file system.•The number of free block in the file system.•A list of free block available in the file system•The index of the next free block in the free block list.•The size of inode list.•The number of free inodes in the file system.•A list of free inodes in the file system.•The index of the next free inode in the free inode list.•Lock fields for both free inode list and free block list•A flag to indicate if the super block is modified.

04/20/23 . 49

Allocation of a new Inode

Free Inode

list

Super Block

Remembered Inode

(the highest free inode

it found before)

Inode List on disk

04/20/23 . 50


Free Inode list in super block is not empty

Free Inodes83 48 empty

Index=19

18 19

Free Inodes83 empty

Index=18

18

04/20/23 . 51


Free Inode list in super block is empty

470 empty

Index=0

Index

0

535

Remembered Inode (the highest free inode it found before)

471475476

Inode Allocated = 470

04/20/23 . 52

ialloc system call ialloc () // allocate a new inode{ if (inode list in super block is empty) { fill up the inode list starting from remembered inode (bread,brelse); Set remembered inode to the last inode found; } get inode number from super block inode list; get inode (algorithm iget); initialize inode; write inode to disk; decrement file system free inode count; return inode;}

04/20/23 . 53

Free of an Inode

Free Inode 499 & 601- Inode free list is full

535 471475476

499

Remembered Inode

471475476

index

index

499 471475476

index

index

Free 499

Free 601

04/20/23 . 54

Free of an Inode

Free Inode 499 & 601- Inode free list is not full

535 476

535

Remembered Inode

499476

index

index

535 601499476

index

Free 499

Free 601

Empty

04/20/23 . 55

ifree system call

ifree (input_inode) // free inode{

increment file system free inode count;if (inode list full){

if (input_inode is less than remembered node)set remembered node to input_inode;

elsestore input_inode in inode list;

}}

04/20/23 . 56

Disk block allocation

Disk blocks are allocated:

•When data is written to a file.

•When indirect block is needed.

04/20/23 . 57

Disk block Allocation

Free block

list

Super BlockFree Block Free Block

04/20/23 . 58

Allocation of disk blocks

109 106 103 100

211 208 205 202

310 307 304 301

409 406 403 400

109

211

310

Super block list

04/20/23 . 59


109

211 208 205 202

109

Super block list

Original Configuration

109

211 208 205 202

109

Super block list

After freeing block number 949

949

04/20/23 . 60


109

211 208 205 202

109

Super block list

After assigning block number 949

211 208 205 202

Super block list

After freeing block number 109

310 307 304 301

211

04/20/23 . 61

alloc System Call

alloc () // file system block allocation{

remove block from free block list;if (removed block is last block in free list){

read block just taken from block free list (bread)Copy blocks number in block into super blockrelease block buffer (brelse)

}get buffer for block just removed from free blk list (getblk)zero buffer contentsdecrement total count of free blocksdark super block modifiedreturn buffer

}

04/20/23 . 62

File System calls

04/20/23 . 63

File System Calls

File System Calls

Open close create dup lseek read write pipe mount umount

Buffer allocation algorithms

Getblk brelse bread breada bwrite

namei

iget iput bmapalloc free ialloc ifree

Low level file system algorithms

04/20/23 . 64

open

The open system call is the first step a process must take to access the data in the file. The syntax for the open system call is:ff

fd = open (pathname,flags);

Pathname : the file name.

Flags: the type of open (e.g. read/write, Read only).

04/20/23 . 65

open

file descriptor open (file name, type of open) // open system calls{

convert file name into inode (algorithm namei)if (file doesn’t exist or not permitted access)

return (error)allocate file table entry for inode, initialize count and offset;allocate user file descriptor entry, set pointer to file table entry;If (type of open specifies truncated file)

free all file blocks (algorithm free)unlock inode;return (user file descriptor);

}

04/20/23 . 66

open

0

1

2

3

4

5

Count 1, Read

Count 1, Read-writeCount 1, write

Count 2, /etc/passwd

Count 1, local

File descriptor table

File Table inode Table

fd1=open (“/etc/ passwd”, O_RDONLY);

fd2 = open (“local”. RDWR);

fd3 = open (“/etc/ passwd ”,O_WRONLY);

Process A

04/20/23 . 67

open

012345

Count 1, Read



Count 1, local

Count 1 private

File Tableinode Table

fd1=open (“/etc/ passwd”, O_RDONLY);

fd2 = open (“private”. O_RDONLY);

Process A

012345

Process BCount 1,

readCount 1,

read

04/20/23 . 68

close

close (file descriptor) // close system calls{

free file descriptor;If (file table count > 0)

decrement file table count;else free file table entry (count = 0);if (inode table count > 0)

decrement inode table count;else

free inode table entry (count = 0)iput (inode)

04/20/23 . 69

close

012345

Count 1, Read



Count 1, local

Count 0 private


Process B: close (fd1); close (fd2);

Process A

012345

Process BCount 0,

readCount 0,

read

04/20/23 . 70

dup

new file descriptor dup (file descriptor) // dup system call{ find a free entry in the file descriptor table; copy the pointer in the file descriptor entry into the new file descriptor; increment the corresponding file table entry;}

Dup system call copies a file descriptor into the first free slot of the user file descriptor table, returning the new file

descriptor table:

newfd = dup (fd)

04/20/23 . 71

dup

Count 1, Read



Count 1, local

Count 0 private


fd = Dup (5); fd will equal 6

Process A

0123456

File Desriptor Table

04/20/23 . 72

mount

Mount file system call connects a file system on a device to an existing hierarchy of another file system.

mount (special pathname, directory path name, options)

Special pathname :the device name for the file to be mounted.

Directory path name: the directory where the file system will be mounted.

Options: read only, read/write.

04/20/23 . 73

mount

mount (/dev/dsk1, “/usr”);

cd /usr/src/uts

bin etc usr

cc date sh

bin include src

cc date sh uts

File system B:/dev/dsk1

File system A:/dev/dsk0

04/20/23 . 74

mount

Device number identifies the mounted file system

A pointer to the buffer containing the file system super block

A pointer to the root inode of the mounted file system (“/” of the /dev/dsk1)

A pointer to the inode of the directory that is the mount point (“usr”).

/dev/dsk1

buffer

Fields of a mount table entry

04/20/23 . 75

mount

Mount point (“usr”) count 1

Root inode of mounted file system

“/” count = 1

Device inode /dev/dsk1 not in use Count = 0

inode Table

Super block

Mounted on inode

Root inode

Data Structure After Mount

Mount Table

04/20/23 . 76

mount void mount (file name of block dev, directory name of mount point, options) {

get inode for block special file (namei)get inode for “mounted on” directoryif (not a directory or reference count > 1)

release inode (algorithm iput)return error

open block device driver for mounted deviceget free buffer from buffer cacheread super block into free bufferget root inode of mounted device (algorithm iget), save in mount tablemark inode of “mounted on” directory as mount pointrelease the inode for the block device driverunlock inode of mount point directory

}

04/20/23 . 77

Distributed File System

04/20/23 . 78

Distributed file system Machine A Machine B

Processor

Memory

Peripheral

Processor

Memory

Peripheral

File system is distributed among multiple physical machines

04/20/23 . 79

Distributed file system

User in machine A can access file(s) in machine B.

bin etc usr

cc date sh

binsrc

cc date shuts

Machine BMachine A

04/20/23 . 80

Distributed file system

System Call Library

System Call Handler

Remote System Call Handler

user

Kernel

Conceptual Kernel Layer for Distributed file system

create a new operating system layer called Remote File System Handler to implement distributed file system.

04/20/23 . 81

Distributed file system Machine A Machine B

Processor

Memory

Peripheral

Processor

Memory

Peripheral

1. Client Stub constructs message with the user requests and send it to the Server Stub.

2. The server stub receives the request, parse and execute the requests and return a response.

Client Stub Server Stub

Remote System Call Handler

04/20/23 . 82


Remote File System Client stub

Remote File System Server stub

ServiceRequest

ServiceAcknowledgment

At least two messages are required to implement Remote File System services

04/20/23 . 83


System call type

Syscall parms

Environment data

Data stream

ServiceRequest

System call type

Error code Data stream

ServiceAcknowledgment

Distributed File System messages structure

04/20/23 . 84


Access Mechanisms:• Explicit Access: The location of the file system should be

added to each file system access operation

(e.g. open (“B:/src/uts”, O_RDONLY))• Implicit Access: the location is specified only during

mounting operation, and then the subsequent operations are used as normal (e.g. open (“/src/uts”, O_RDONLY))

04/20/23 . 85

Distributed file system (explicit access)

cd B:/usr/src

open (“B:/usr/src/uts”, O_RDONLY)

bin etc usr

cc date sh

binsrc

cc date shuts

Machine BMachine A

04/20/23 . 86

Distributed file system (explicit type)

File Table

inode Table

File Desriptor

Table

Remote file system Server Stub

Remote file

system client stub

Machine A Machine B

File Desriptor

Table

04/20/23 . 87

Distributed File System (example open)

1.kernel in the client machine construct a message with system call type “remote open” with the file name and other parameters.

2.The kernel send this message into the server machine.

3.The distributed file system stub in the server machine allocates a user file descriptor, file table, and inode entries for the requested file.

4.The file system stub in the server machine returns an index to the file descriptor.

5.The user in the client machine uses this file descriptor for subsequent operations such as read, write etc.

04/20/23 . 88

Distributed file system (implicit access)

Remote mount

mount (B:/dev/dsk1, “/usr”);

cd /usr/src

open (“/usr/src/uts”, O_RDONLY)

bin etc usr

cc date sh

binsrc

cc date shuts

Machine BMachine A

04/20/23 . 89

Distributed file system (implicit type)

File Table

inode Table

File Desriptor

Table

Remote file system Client Stub

inode Table

Remote file system Server stub

Machine A Machine B

04/20/23 . 90

Distributed File System (example open)

1.kernel in the client machine construct a message with system call type “remote open” with the file name and other parameters.

2.The kernel send this message into the server machine.

3.The distributed file system stub in the server machine allocates a inode entry for the requested file.

4.The file system stub in the server machine returns an identifier for the server stub.

5.The client machine allocate file descriptor, file table and inode table entries. The allocated file descriptor will be used for subsequent file operations.

Date post:	03-Jan-2016
Category:	Documents
Upload:	dayna-griffin
View:	215 times
Download:	0 times

10/23/2015.1 File System Architecture. 10/23/2015.2 / bin unixdev etc user jim mike x y z tty00...

Documents