1. 10/23/2015.1 File System Architecture

2. 10/23/2015.2 / bin unixdev etc user jim mike x y z tty00 tty01 File System architecture

3. 10/23/2015.3 File System Layout Super block Inode list Data BlocksBoot 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 information in the files.

4. 10/23/2015.4 disk The Buffer Cache 12 34 13 read file block Memory write file block

5. 10/23/2015.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

6. 10/23/2015.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

7. 10/23/2015.7 Structure Of Buffer Header Device num Block num status Data area 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.

8. 10/23/2015.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.

9. 10/23/2015.9 Buffer Functions getblk: allocate buffer for read or write. brelse: release buffer when it is not needed any more.

10. 10/23/2015.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

11. 10/23/2015.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.

12. 10/23/2015.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 (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.

13. 10/23/2015.13 Buffer Allocation: Scenario 2 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

14. 10/23/2015.14 Buffer Allocation: Scenario 2 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.

15. 10/23/2015.15 Buffer Allocation: Scenario 3 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. Search for block 18-not in cache Delayed write

16. 10/23/2015.16 Buffer Allocation: Scenario 3 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

17. 10/23/2015.17 Buffer Allocation: Scenario 3 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

18. 10/23/2015.18 Buffer Allocation: Scenario 3 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

19. 10/23/2015.19 Buffer Allocation: Scenario 3 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

20. 10/23/2015.20 Buffer Allocation: Scenario 4 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. Search for block 18-not in cache sleep

21. 10/23/2015.21 Buffer Allocation: Scenario 5 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 busy

22. 10/23/2015.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

23. 10/23/2015.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 4 3 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.

24. 10/23/2015.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

25. 10/23/2015.25 brelse system call brelse (locked buffer) { wakeup all procs waiting for any buffer to be free wakeup all procs waiting for this buffer to be free if (buffer is valid and not old and buffer not old) Enqueue buffer at the end of the free list else Enqueue buffer at the beginning of free list unlock (buffer) }

26. 10/23/2015.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 }

27. 10/23/2015.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. 10/23/2015.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.

29. 10/23/2015.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. 10/23/2015.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.

31. 10/23/2015.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 bmap alloc freeialloc ifree Lower level file system algorithms

32. 10/23/2015.32 File System Data Structure User File DescriptorFile 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. 10/23/2015.33 Inode list 0123456789 12345678910111213141516 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

34. 10/23/2015.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. 10/23/2015.35 Active Inode Hash table & Free list inode Free list

36. 10/23/2015.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 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. 10/23/2015.37 iput system call iput () { lock inode Decrement inode reference count If (reference count == 0) { If (inode link count == 0) { Free disk blocks for file (function 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. 10/23/2015.38 Allocation of contagious blocks for file File A File BFile C 40506070 File A freeFile C 40506070 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).

39. 10/23/2015.39 Block File Allocation-inode fixed size 1234567891011121314151617181920 25461613128151718192010 No fragmentation problem. Since the inode is fixed, it is difficult to increase file size

40. 10/23/2015.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

41. 10/23/2015.41 Minimize fragmentation & Varying the file size Direct 0 Direct 1 Direct 2 Direct 4 Direct 5 Direct 6 Direct 7 Direct 8 Direct 9 Single indirection Double indirection Triple indirection

42. 10/23/2015.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

43. 10/23/2015.43 Block Layout of a sample file 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 9156 Block 331 Block 3333 Block 367 0

44. 10/23/2015.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 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 Bytes Process wants to access byte offset 9000 Block # = (9000/1024) = 8 starting from 0 (block # 367) Offset within block = 9000- 8*1024 = 808 th 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 0 th single indirect block-block # 331 Byte number 969 is in the 0 th (969/1024)direct block – block # 3333

45. 10/23/2015.45 bmap system call bmap () // map logical offset into physical block # { if (offset <=10 K) indirection level = 0 else if (offset > 10K & <= 256K) indirection level = 1 else if (offset>256K & <= 64M) indirection level = 2 else if (offset > 64M) indirection level = 3 for ( l=1; l < 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 #) }

46. 10/23/2015.46 Directories structure Byte offsetInode number 2 bytes File name 14 bytes 083. 162.. (parent) 321798init 4885fsk 64108mount 801544passwd 962344mknod 112567mkfs

47. 10/23/2015.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/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 }

48. 10/23/2015.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.

49. 10/23/2015.49 Allocation of a new Inode Free Inode list Super Block Remembered Inode (the highest free inode it found before) Inode List on disk

50. 10/23/2015.50 Allocation of a new Inode Free Inode list in super block is not empty Free Inodes 8348 empty Index=19 1819 Free Inodes 83 empty Index=18 18

51. 10/23/2015.51 Allocation of a new Inode 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

52. 10/23/2015.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; }

53. 10/23/2015.53 Free of an Inode Free Inode 499 & 601- Inode free list is full 535 471475476 499 Remembered Inode 471475476 index 499 471475476 index Free 499 Free 601

54. 10/23/2015.54 Free of an Inode Free Inode 499 & 601- Inode free list is not full 535 476 535 Remembered Inode 499476 index 535 601499476 index Free 499 Free 601 Empty

55. 10/23/2015.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; else store input_inode in inode list; }

56. 10/23/2015.56 Disk block allocation Disk blocks are allocated: When data is written to a file. When indirect block is needed.

57. 10/23/2015.57 Disk block Allocation Free block list Super Block Free Block

58. 10/23/2015.58 Allocation of disk blocks 109106103100211208205202310307304301409406403400 109 211 310 Super block list

59. 10/23/2015.59 Allocation of disk blocks 109 211208205202 109 Super block list Original Configuration 109 211208205202 109 Super block list After freeing block number 949 949

60. 10/23/2015.60 Allocation of disk blocks 109 211208205202 109 Super block list After assigning block number 949 211208205202 Super block list After freeing block number 109 310307304301 211

61. 10/23/2015.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 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 dark super block modified return buffer }

62. 10/23/2015.62 File System calls

63. 10/23/2015.63 File System Calls Open close create dup lseek read write pipe mount umount Buffer allocation algorithms Getblk brelse bread breada bwrite namei iget iput bmap alloc freeialloc ifree Low level file system algorithms

64. 10/23/2015.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).

65. 10/23/2015.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); }

66. 10/23/2015.66 open 0 1 2 3 4 5 Count 1, Read Count 1, Read-write Count 1, write Count 2, /etc/passwd Count 1, local File descriptor table File Tableinode Table fd1=open (“/etc/ passwd”, O_RDONLY); fd2 = open (“local”. RDWR); fd3 = open (“/etc/ passwd ”,O_WRONLY); Process A

67. 10/23/2015.67 open 0 1 2 3 4 5 Count 1, Read Count 1, Read-write Count 1, write Count 3, /etc/passwd Count 1, local Count 1 private File Table inode Table fd1=open (“/etc/ passwd”, O_RDONLY); fd2 = open (“private”. O_RDONLY); Process A 0 1 2 3 4 5 Process B Count 1, read

68. 10/23/2015.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)

69. 10/23/2015.69 close 0 1 2 3 4 5 Count 1, Read Count 1, Read-write Count 1, write Count 2, /etc/passwd Count 1, local Count 0 private File Table inode Table Process B: close (fd1); close (fd2); Process A 0 1 2 3 4 5 Process B Count 0, read

70. 10/23/2015.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)

71. 10/23/2015.71 dup Count 1, Read Count 1, Read-write Count 2, write Count 2, /etc/passwd Count 1, local Count 0 private File Table inode Table fd = Dup (5); fd will equal 6 Process A 0 1 2 3 4 5 6 File Desriptor Table

72. 10/23/2015.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.

73. 10/23/2015.73 mount mount (/dev/dsk1, “/usr”); cd /usr/src/uts bin etc usr ccdatesh bin include src ccdateshuts File system B:/dev/dsk1 File system A:/dev/dsk0

74. 10/23/2015.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

75. 10/23/2015.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

76. 10/23/2015.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” directory if (not a directory or reference count > 1) release inode (algorithm iput) return error open block device driver for mounted 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 }

77. 10/23/2015.77 Distributed File System

78. 10/23/2015.78 Distributed file system Machine A Machine B Processor Memory Peripheral Processor Memory Peripheral File system is distributed among multiple physical machines

79. 10/23/2015.79 Distributed file system User in machine A can access file(s) in machine B. bin etc usr ccdatesh bin src ccdatesh uts Machine BMachine A

80. 10/23/2015.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.

81. 10/23/2015.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

82. 10/23/2015.82 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

83. 10/23/2015.83 Distributed File System System call type Syscall parms Environment data Data stream ServiceRequest System call type Error code Data stream ServiceAcknowledgment Distributed File System messages structure

84. 10/23/2015.84 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))

85. 10/23/2015.85 Distributed file system (explicit access) cd B:/usr/src open (“B:/usr/src/uts”, O_RDONLY) bin etc usr ccdatesh bin src ccdatesh uts Machine BMachine A

86. 10/23/2015.86 Distributed file system (explicit type) File Table inode Table File Desriptor Table Remote file system Server Stub Remote file system client stub Machine AMachine B File Desriptor Table

87. 10/23/2015.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.

88. 10/23/2015.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 ccdatesh bin src ccdatesh uts Machine BMachine A

89. 10/23/2015.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 AMachine B

90. 10/23/2015.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.