Transcript No Slide Title

Files in Unix
From the System's View
1
File Handling Data Structures

Process Table
 File Table
 V-Node Table
 inodes
2
Process Table
Process A
Process B
Process C
File Descriptor
Flags
Pointer to
File Table Entry
File
Table
Entry
Process D
3
File Table
File 1
File Status Flags
Read, Write, Etc.
File 2
Current File Offset
File 3
Pointer to V-node
Table Entry
File 4
File Table for
Open Files
V-node Table
4
V-Node Table Entry
File Type
File
Table
Entry
Pointers to Functions
for this File
Inode Information
Disk Drive
V-node Table
Entry
5
File Types

Regular files
 Directory files
 Character special files
 Block special files
 FIFOs
 Sockets
 Symbolic Links
6
Special File Protection Bits

Group Locking

Set group/User ID on execution

Sticky Bit (saved-text-bit)
7
Disk Drives and File Systems
Partition
Partition
Partition
File System
i-list
Boot
Block
directory blocks and data blocks
Super
Block
inode
inode
inode
inode
inode
8


Layout:
 Boot area: Bootstrap code
 Superblock: Attributes and metadata of file system
 Inode list: one inode/file 64 bytes, fix the size of file
system
 Data area: files, directories and indirect blocks which
hold pointers to other file data blocks
Directories:
 File containing list of files and subdirectories
 Fixed record of 16 bytes
9
inodes

inodes contain a lot of information about a file
 mode
and type of file
 number of links to the file
 owner's UID
 owners GID
 number of bytes in file
 times (last accessed, modified, inode changed)
 physical disk addresses (direct and indirect blocks)
 number of blocks
 access information
10
File Systems Expanded
B S
inode
i-list
inode
data
data
directory data
directory
data
data
data
inode
inode # File Name
inode # File Name
inode # File Name
11
bytes ( 216= 65535 files) inode number, 14 bytes file
name
 0 inode number means file no longer exist
 Root directory and parent have inode number equal to 2
2
73
38
9
0
110
65
.
..
File1
Deleted file
Subdirectory1
File2
12

Inodes ( Index nodes):
 Each
file has one unique inode
 Inode contains metadata of the file
 on-disk inode and in-core inode
Field
Size
Description
di_mode
2
File type, permissions
di_uid
2
Owner UID
di_gid
2
Owner GID
di_size
4
Size in bytes
di_addr
39
Array of block addresses
:
:
:
13

di_addr:
 File
is not stored in contiguous blocks, prevents
fragmentation
 An array of block address is required, Stored in inode,
prevent extra read
 Size of array depends on the size of file
0
1
2
3
4
5
6
7
8
9
10
11
12
indirect
Double indirect
triple indirect
14
Direction and Indirection
inode
Direct 0
Direct 1
Direct 2
Direct 3
Direct 4
Direct 5
Direct 6
Direct 7
Direct 8
Direct 9
Sgl Ind
Dbl Ind
Triple Ind
Disk
Blocks
15
In-core inodes

When a file is being used, it's inode is copied to
memory (core) and additional fields are added
 access
status
 node is locked
 process is waiting for node to unlock
 in-core inode has been modified
 file has changed so inode has also changed
 Number of processes using inode and file
 Device ID and disk address where inode is located
 Current file position
16
RFS (Remote File System)

An AT&T invention
 Independent of any particular network hardware
or software
 Designed for transparent sharing of disk storage
and peripherals
 RFS mounts a remote directory structure under
an existing structure in the user's filesystem
 Remote
files are then accessed as though they are part
of the local file system

RFS also supports special files and named pipes
17
System V File System (s5fs)




Single logical disk or partition, one FS per partition
Each FS has own root, sub directories, Files, data and
metadata
Disk Block = 512 * n, granularity of disk allocation for a file
Translated by disk drivers in to track sectors and cylinders
B
Boot area
S
Inode list
Data blocks
superblock
18

Superblock
 Metadata
about File system
 One Superblock per File system
 Kernel reads Superblock when mounting the File
system
 Superblock contains following information
 Size in blocks of the file system
 Size in blocks of the inode list
 Number of free blocks and inodes
 Free block list (Partial)
 Free inode list (Full)
19
Kernel Organization

In-Core Inodes
 Represented by struct inode
 All fields of on-disk inode and following extra fields
vnode: contains the vnode of the file
 Device ID of the partition containing the file
 Inode number of the file
 Flags for synchronization and cache management
 Pointers to keep the inode on a free list
 Pointers to keep the inode on a hash queue
 Block number of last block read

20

Inode Lookup
 Lookuppn(), a file system independent function performs
pathname parsing
 When searching s5fs directory it translates to a call to
s5lookup()
 s5lookup first checks directory name lookup cache
 On miss it reads the directory one block at a time
 If directory contains a valid filename entry, s5lookup()
obtains inode number of file
 iget() is called to locate inode
 iget() searches the appropriate hash table to get the
inode
21

The server keeps track of how many remote users
have the file open at a given time
 Server also maintain security by distinguishing
between local and remote opens
 Remote access can be restricted to the privileges
of selected local accounts
22
NFS (Network File System)

Developed by Sun Microsystems
 Design goal was portability to other OS's and
architectures
 Uses RPCs (Remote Procedure Calls) for
protocol definition and remote system access
 Uses the External Data Representation (XDR) to
define data in a machine independent manner
 Furthers machine independence by defining a
Virtual File System (VFS) that defines operations
that can be performed on a file
23

NFS fileservers are stateless and do not track the
state of files or provide any standard Unix file
locking capabilities
 Conflicts

among users of the same file can arise
Sun has provided a locking scheme by
maintaining client requested locks in memory only
 Both
client and server keep locks in memory for
consistency
 However, because of the tight coupling between client
and server, loss of a server can cause data consistency
problems
24

NFS does not allow shared root filesystems
 In
concept, shared directories like /dev, /bin, and /etc
should reside on a common file server
 This simplifies the design but the failure of the
fileserver then impacts all attached nodes
 The user or sysadmin must know what directories
should be mounted at each network node
 The number of required mounts can take quite a while
to perform on system reboot

Since files are shared in place (on the server)
there are no revision conflicts
25

The stateless nature of NFS (except for the
locking kludge) ensures consistency of the system
after recovery from a crash
26