File System Architecture for UNIX

1
File System Architecture for UNIX
2
File System Definition

1. The collection of files and file management
   structures on a physical or logical mass storage
   device, such as a diskette or disk
2. the way the files are organized on the disk and
   the methods and data structures that an operating
   system uses to keep track of files on a disk or
   partition.
3. A data structure that translates the a logical
   (files, directories) structure into physical
   (sector) it helps both computers and users to
   locate files.

3
File System Architecture for UNIX
/
bin
etc
unix
dev
user
tty01
tty00
mike
jim
y
x
z
4
File System Layout
Super block
Inode list
Data Blocks
Boot block
Boot Block first sector, contains bootstrap
code to initialize the operating system
Super Block how many file it can store, where
to find free space
Inode 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
the files information.
5
The Buffer Cache
disk
read file block
Memory
1
2
1
3
3
4
write file block
6
buffer allocation algorithms
getblk allocate buffer in memory. brelse
release buffer. bread read disk block breada
read block ahead. bwrite write a disk block
7
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
Hash queue headers table
Header (3)
data
Header (35)
data
Freelist header

• Buffer exists in
• Hash queue free list.
• Or in hash queue.

8
Structure Of Buffer Header
Data area
Device num
Block num
status





Ptr to prev 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.

9
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 kernel is currently reading or writing to the
  contents to disk.
• A process is waiting for the buffer to become
  free.

10
Buffer Functions

• getblk allocate buffer for read or write.
• brelse release buffer when it is not needed any
  more.

11
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
12
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
Hash queue headers table
(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.
13
Buffer Allocation Scenario 1
(28)
data
(64)
data
(4)
data
Block no 0 mod 4
Block no 1 mod 4
Block no 2 mod 4
Block no 3 mod 4
(17)
data
(97)
data
(5)
data
(98)
data
(10)
data
(50)
data
Hash queue headers table
(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.

14
Buffer Allocation Scenario 2
Search for block 18-not in cache
(28)
data
(64)
data
(4)
data
Block no 0 mod 4
Block no 1 mod 4
Block no 2 mod 4
Block no 3 mod 4
(17)
data
(97)
data
(5)
data
Hash queue headers table
(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.
15
Buffer Allocation Scenario 2
(28)
data
(64)
data
(4)
data
Block no 0 mod 4
Block no 1 mod 4
Block no 2 mod 4
Block no 3 mod 4
(17)
data
(97)
data
(5)
data
(98)
data
(10)
data
(50)
data
(18)
data
Hash queue headers table
(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.

16
Buffer Allocation Scenario 3
Search for block 18-not in cache
(28)
data
(64)
data
(4)
data
Block no 0 mod 4
Block no 1 mod 4
Block no 2 mod 4
Block no 3 mod 4
(17)
data
(97)
data
(5)
data
Delayed write
(98)
data
(10)
data
(50)
data
Hash queue headers table
(3)
data
(99)
data
(35)
data
Freelist header
Delayed write
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.
17
Buffer Allocation Scenario 3
(28)
data
(64)
data
(4)
data
Block no 0 mod 4
Block no 1 mod 4
Block no 2 mod 4
Block no 3 mod 4
(17)
data
(97)
data
(5)
data
delayed write
Hash queue headers table
(98)
data
(10)
data
(50)
data
(3)
data
(99)
data
(35)
data
Freelist header
delayed write

• The kernel takes off block 3,5 from freelist.
• The kernel mark them as old to be placed in front
  of the queue
• The kernel start asynchronous write for block 3,5.

18
Buffer Allocation Scenario 3
(28)
data
(64)
data
(17)
data
(97)
data
(5)
data
Block no 0 mod 4
Block no 1 mod 4
Block no 2 mod 4
Block no 3 mod 4
writing
(18)
data
(98)
data
(10)
data
(50)
data
(3)
data
(99)
data
(35)
data
Freelist header
writing

• The kernel will allocate buffer 4, release it
  from the free list.
• Assign the device and block (18) for the
  buffer.
• Place the buffer in the correct hash queue.

19
Buffer Allocation Scenario 3
(28)
data
(64)
data
Block no 0 mod 4
Block no 1 mod 4
Block no 2 mod 4
Block no 3 mod 4
(17)
data
(97)
data
(5)
data
Writing complete
(18)
data
(98)
data
(10)
data
(50)
data
Hash queue headers table
(3)
data
(99)
data
(35)
data
Freelist header
writing complete
When the buffer writing is complete blocks 3,5
will be placed in the free list.
20
Buffer Allocation Scenario 4
Search for block 18-not in cache
(28)
data
(64)
data
(4)
data
(17)
data
(97)
data
(5)
data
Block no 0 mod 4
Block no 1 mod 4
Block no 2 mod 4
Block no 3 mod 4
(98)
data
(10)
data
(50)
data
sleep
(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 is execute brelse,
release a buffer, and wake up processes waiting
fro this event.
21
Buffer Allocation Scenario 5
Search for block 99 block is busy
(28)
data
(64)
data
(4)
data
Block no 0 mod 4
Block no 1 mod 4
Block no 2 mod 4
Block no 3 mod 4
(17)
data
(97)
data
(5)
data
Delayed write
(98)
data
(10)
data
(50)
data
Hash queue headers table
(3)
data
(99)
data
(35)
data
Freelist header
busy
Delayed write
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
22
Buffer Allocation Scenario 5
Process A
Process B

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

• 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

The kernel finds the block on hash queue, but the
buffer is busy.
23
Race Condition
Process A
Process B
Process C
1

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

2

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

3
4

• Sleep waiting for a free buffer

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

5

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

6

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

24
getblk system call
locked buffer 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
25
brelse system call
brelse (locked buffer) if (buffer is valid and
not old) Enqueue buffer at the end of the free
list else Enqueue buffer at the beginning
of free list wakeup all procs waiting for any
buffer to be free wakeup all procs waiting for
this buffer to be free unlock (buffer)
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 old, to put at head of free list
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
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, synchronous
  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 doesnt wait for the second block to
  be read.

29
breada system call
breada Input 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 read sleep (event first
buffer contains valid data) return buffer else
// first block in cache read first block
(bread) return buffer
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 insure 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.

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

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
33
Inode list
Disk blocks-each 512 bytes
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
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
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
35
Active Inode Hash table Free list
Inode Table










inode
inode
inode
inode
inode
inode
inode
inode
Free list

• Inode exists
• Inode queue inode free list.
• Inode queue.

36
iget system call
//allocate in core inode locked inode iget (file
system inode number) 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
list increment reference count by 1 return
inode If (no node in free list) Return
error remove new inode from free list Remove
inode from old hash queue, and place on new
one read inode from Disk (bread) increment inode
reference count by 1
37
iput system call
//release in core inode iput ( pointer to in core
inode) lock inode decrement inode reference
count If (reference count 0) If (inode
link count 0) free disk blocks for file
(algorithm free) Set type to 0 Free inode
(function ifree) If (file is accessed or modified
or inode modified) Update disk inode put inode in
free list unlock inode
38
File Allocation contagious file block allocation

40
50
60
70
File B
40
50
60
70
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).

39
File Allocation 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 16
1 3 12 8 15
17 18 19 20 10

• No fragmentation problem.
• Since the inode is fixed, it is difficult to
  increase file size

40
File Allocation Block size selection
Difficult to find a point which minimize
fragmentation and maximize file size
Decreasing block size will decrease block
fragmentation
Increasing block size will increase file size for
fixed size inode
41
File Allocation 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 9
Single indirection
Double indirection
Triple indirection
























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 256 block numbers
256
43
Block Layout of a sample file
4096 0
1
45432 2
0 3
0 4
5
0 6
101 7
8
0 9
428 10
9156 11
824 12
Block 4096
Block 228
Block 367


3333

331



Block 3333
75
Block 331
Block 9156
44
Block Layout of a sample file
Maximum file size-1K Bytes per block 10 direct
blocks with 1K bytes each 10K bytes 1 indirect
blocks with 256 direct blocks 256K bytes 1
double indirect blocks with 256 indirect blocks
64M bytes 1 triple indirect blocks with 256
double indirect blocks 16G Bytes
Process wants to access byte offset 9000 Block
(9000/1024) ?? Offset within block ??
Block (9000/1024) 8 starting from 0
(block 367) Offset within block 9000- 81024
808th byte from block 367
45
Block Layout of a sample file (continue)
Maximum file size-1K Bytes per block 10 direct
blocks with 1K bytes each 10K bytes 1 indirect
blocks with 256 direct blocks 256K bytes 1
double indirect blocks with 256 indirect blocks
64M bytes 1 triple indirect blocks with 256
double indirect blocks 16G Bytes
Process wants to access byte offset
350000 Block ?? Offset within block ??
Process wants to access byte offset
350000 First byte accessed by double indirect
block 256K 10K 272,616 byte Offset within
block 350000-272616 77616 Entry of First
indirect block 77616/256K 0 entry -block
331 Entry of Second indirect block
(77616/1024) 75th entry block 3333 Offset
within block 3333 (77616) 1024 816 byte
46
bmap system call
// map logical offset into physical block
Block , byte offset bmap (inode, byte
offset) if (offset lt10 K) indirection level
0 else if (offset gt 10K lt 256K) indirection
level 1 else if (offsetgt256K lt 64M)
indirection level 2 else if (offset gt 64M)
indirection level 3 for ( l1 l lt indirection
level l) calculate indirect block from
file offset read indirect block using
bread release an old indirect block using
brelse calculate direct block return (block
, offset)
47
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
96 1544 passwd
112 2344 mknod
128 567 mkfs
48
namei system call
namei () // convert path name to inode If (path
name start from root) // /user/cse8343/jim
working node root node (alg iget) else //
./cse8343/jim working node current directory
inode (alg iget) while (there is more path
name) read next path name component from
input verify that working inode is of directory
and permission is ok read directory working
inode by using bmap bread and brelse if
(component matches an entry in directory (working
inode) get inode number for match
component releases working inode (alg
iput) working inode inode matched component
(alg iget) else // component not in
directory return no node return working inode
49
Supper 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.

50
Allocation of a new Inode
Super Block
Inode List on disk

Remembered Inode (the highest free inode it
found before)
Free Inode list
51
Allocation of a new Inode
Free Inode list in super block is not empty
18
19
Free Inodes
empty
83
48
Index19
18
Free Inodes
empty
83
Index18
52
Allocation of a new Inode
Free Inode list in super block is empty
0
empty
470
Remembered Inode (the highest free inode it found
before)
Index0
471
475
476
535
Index
Inode Allocated 470
53
ialloc system call
locked inode ialloc (file system) // allocate a
new inode from disk 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 locked inode
54
Free of an Inode
Free Inode 499 601- Inode free list is full
471
475
476
535
Remembered Inode
index
471
475
476
499
Free 499
index
index
471
475
476
499
Free 601
index
55
Free of an Inode
Free Inode 499 601- Inode free list is not full
476
Empty
535
Remembered Inode
index
499
476
535
Free 499
index
601
499
476
535
Free 601
index
56
ifree system call
ifree (input_inode) // free inode on
disk increment file system free inode count if
(inode list full) if (input_inode is less than
remembered node) set remembered node to
input_inode else store input_inode in inode
list
57
Disk block allocation

• Disk blocks are allocated
• When data is written to a file.
• When indirect block is needed.

58
Disk block Allocation
Free Block
Free Block
Super Block
Free block list
On Disk
59
Allocation of disk blocks
Super block list
On Disk
109
211
310
60
Allocation of disk blocks
Super block list
109
109
Original Configuration
Super block list
109
949
109
After freeing block number 949
61
Allocation of disk blocks
Super block list
109
109
After assigning block number 949
Read from disk
Super block list
211
After freeing block number 109
62
alloc System Call
// file system block allocation buffer for new
block alloc (file system) 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 block release block buffer
(brelse) get buffer for block just removed from
free blk list (getblk) zero buffer
contents decrement total count of free
blocks mark super block modified return buffer
63
File System calls
64
File System Calls
file System Calls
Open close create dup lseek read write pipe mount
umount
low level file system algorithms
buffer allocation algorithms
getblk brelse bread breada bwrite
65
open system call
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 isff fd open
(pathname,flags) pathname the file
name. flags the type of open (e.g. read/write,
Read only).
66
open system call (continue)
Process A
File descriptor table
inode Table
File Table
fd1 open (/etc/ passwd, O_RDONLY) fd2 open
(local. RDWR) fd3 open (/etc/ passwd
,O_WRONLY)
67
Open system call (continue)
Process A
Count 1, Read
Count 1, Read-write
Count 1, write
Process B
Count 1, read
Count 1, read
File Table
inode Table
fd1open (/etc/ passwd, O_RDONLY) fd2 open
(private. O_RDONLY)
68
open system call (continue)
// open system calls file descriptor open (file
name, type of open) convert file name into
inode (algorithm namei) if (file doesnt exist
or not permitted access) return (error) alloc
file table entry for inode, initialize count and
offset alloc 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)
69
close system call
Process A
Count 1, Read
Count 1, Read-write
Count 1, write
Process B
Count 0, read
Count 0, read
File Table
inode Table
Process B close (fd1) close (fd2)
70
close system call
// close system calls close (file descriptor)
free file descriptor If (file table count gt
0) decrement file table count else
free file table entry (count 0) if (inode
table count gt 0) decrement inode table
count else free inode table entry (count
0) iput (inode)
71
dup system call
inode Table
File Table
Process A
0
Count 2, /etc/passwd
1
Count 1, Read
2
3
Count 1, local
Count 1, Read-write
4
5
Count 0 private
Count 2, write
6
File Desriptor Table
fd Dup (5) fd will equal 6
72
dup system call (continue)
// dup system call new file descriptor dup (file
descriptor) 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 file free slot of the first free slot of
the user file descriptor table, returning the new
file descriptor table newfd dup (fd)
73
mount system call
File system A/dev/dsk0
File system B/dev/dsk1
bin
src
include
cc
date
sh
uts
mount (/dev/dsk1, /usr) cd /usr/src/uts
74
mount system call (continue)
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.
75
mount system call (continue)
/dev/dsk1
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).
buffer
Fields of a mount table entry
76
mount system call (continue)
inode Table
Mount Table
Mount point (usr) count 1
Super block Mounted on inode Root inode
Device inode /dev/dsk1 not in use Count 0
Root inode of mounted file system / count 1
Data Structure After Mount
77
mount system call (continue)
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 directory (namei) if (not a
directory or reference count gt 1) release inode
(algorithm iput) return error find empty
slot in mount table (initialize with major
minor device ) open block device driver for
mounted device (using major minor device )
get free buffer from buffer cache read super
block into free buffer get root inode of
mounted device (algorithm iget), save in mount
table mark inode of mounted on directory
as mount point release the inode for the
block device driver unlock inode of mount
point directory
The mounted on directory inode reference count
must not be greater than 1. Assume that we have
/mnt/a/b/c and we mount a file system into /mnt/.
What happen if we execute pwd.
78

• Distributed File System

79
Distributed file system
Machine A
Machine B
File system is distributed among multiple
physical machines
80
Distributed file system
Machine B
Machine A
bin
src
cc
date
sh
uts
User in machine A can access file(s) in machine B.
81
Distributed file system
System Call Library
user
System Call Handler
Kernel
Remote System Call Handler
Conceptual Kernel Layer for Distributed file
system
create a new operating system layer called Remote
File System Handler to implement distributed file
system.
82
Distributed file system
Machine A
Machine B
Client Stub
Server Stub
Remote System Call Handler

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.

83
Distributed File System
Remote File System Client stub
Remote File System Server stub
ServiceRequest
ServiceAcknowledgment
At least two messages are required to implement
Remote File System services
84
Distributed File System
ServiceRequest
System call type
Error code
Data stream
ServiceAcknowledgment
Distributed File System messages structure
85
Distributed File System

• 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))

86
Distributed file system (explicit access)
Machine B
Machine A
bin
src
cc
date
sh
uts
cd B/usr/src open (B/usr/src/uts, O_RDONLY)
87
Distributed file system (explicit type)
Machine A
Machine B
Remote file system Server Stub
Remote file system client stub
File Desriptor Table
File Desriptor Table
File Table
inode Table
88
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.

89
Distributed file system (implicit access)
Machine B
Machine A
bin
src
cc
date
sh
uts
Remote mount mount (B/dev/dsk1, /usr) cd
/usr/src open (/usr/src/uts, O_RDONLY)
90
Distributed file system (implicit type)
Machine A
Machine B
Remote file system Client Stub
Remote file system Server stub
File Desriptor Table
inode Table
File Table
inode Table
91
Questions

• inode allows maximum file name of 14 characters.
  How can we redesign the file systems to include
  arbitrary length of file name.
• Design a directory structure which improves the
  efficiency of searching for path names by
  avoiding linear search.
• Design a scheme that reduces the number of
  directory searches for file names.
• Discuss other schemes to keep track of free disk
  blocks instead the linked list approach.
• Can we mount two UINX file systems with file
  names different in sizes?