SlideShare une entreprise Scribd logo
1  sur  33
How UNIX Organizes and Accesses Files on Disk
Why File Systems 
 File system is a service which supports an abstract representation of the secondary 
storage to the OS 
 A file system organizes data logically for random access by the OS. 
 A virtual file system provides the interface between the data representation by the 
kernel to the user process and the data presentation to the kernel in memory. The file 
and directory system cache. 
 Because of the performance disparity between disk and CPU/memory, file 
system performance is the paramount issue for any OS
Main memory vs. Secondary storage 
 Small (MB/GB) 
 Expensive 
 Fast (10-6/10-7 sec) 
 Volatile 
 Directly accessible by CPU 
Interface: (virtual) memory 
address 
 Large (GB/TB) 
 Cheap 
 Slow (10-2/10-3 sec) 
 Persistent 
 Cannot be directly accessed 
by CPU 
– Data should be first 
brought into the main 
memory
Secondary storage (disk) 
 A number of disks directly attached to the computer 
 Network attached disks accessible through a fast network - Storage Area Network (SAN) 
 Simple disks (IDE, SATA) have a described disk geometry. Sector size is the minimum 
read/write unit of data (usually 512Bytes) 
 Access: (#surface, #track, #sector) 
 Smart disks (SCSI, SAN, NAS) hide the internal disk layout using a controller type function 
 Access: (#sector) 
 Moving arm assembly (Seek) is expensive 
 Sequential access is x100 times faster than the random access
Internal disk structure 
 Disk structure
User Process Accessing Data 
 Given the file name. Get to the file’s FCB using the file system catalog (Open, Close, 
Set_Attribute) 
 The catalog maps a file name to the FCB 
 Checks permissions 
 file_handle=open(file_name): 
 search the catalog and bring FCB into the memory 
 UNIX: in-memory FCB: in-core i-node 
 Use the FCB to get to the desired offset within the file data: 
(CREATE, DELETE, SEEK, TRUNCATE) 
 close(file_handle): release FCB from memory
Catalog Organization (Directories) 
 In UNIX, special files (not special device files) called directories contain information about 
other files. A UNIX directory is a file whose data is an array or list of (filename, i-node#) 
pairs. 
 it has an owner, group owner, size, access permissions, etc. 
 many file operations can be used on directories 
 As a file, a directory has an I-node type structure. 
 A flag in the structure indicates its type. 
 Unlike other files, the kernel imposes a structure on directory files using mkdir. 
 A directory is a sequence of lines , a sequence of directory entries of variable length where 
each line contains an i-node number and a file name mapping: <filename, inode #> 
 Directory data is stored as binary, cannot use cat. But some older UNIXs allow: od -c dir-name. 
 Although directories are files, UNIX permissions – rwx- have slightly different meanings: 
- r, lists directoy contents 
- w, add a file to the directory 
- x, cd to the directory
Subdirectories 
 mkdir subdir causes: 
 the creation of a subdir directory file and an i-node for it 
 an i-node number and name are added to the parent directory file 
120 
207 
135 
“fred.html” 
“abc” 
“bookmark.c” 
201 “subdir” 
• “.” and “..” are stored as ordinary file names with i-node numbers 
pointing to the correct directory files. 
ben 
book memos
Subdirectories in more detail: 
Directory ben 
123 
247 
260 
“.” 
“..” 
“book” 
401 “memos” 
Directory book 
260 
123 
566 
“.” 
“..” 
“chap1” 
567 “chap2” 
590 “chap3” 
Directory memos 
401 
123 
800 
“.” 
“..” 
“kh” 
810 
077 
“kd” 
590 “mw”
Directory block or chunk 
 Directories are allocated in chunks. Each chunk can be read/written in a single I/O operation, 
Why? Performance.
Regular Files and I-nodes 
 Information about each regular local file is contained in a structure called an INODE. 
Containing the file FCB information. 
 There is 1-to-1 mapping between the INODE and a file. However a file may have multiple 
INODES. Large files may in fact multiple layers of INODE’s using indirection to keep track 
of data blocks. 
 Each INODE is identified through its number, a non-negative integer as an index into - 
 The INODE hash array is a list of allocated INODE‘s located at the beginning of the file 
system 
 INODE structures (UNIX i-node list) are stored on the file system block device (e.g., disk) in 
a predefined location on the disk. UNIX: the i-node list. Where it is exactly is file system 
implementation specific. 
 INODE numbers have only local meaning (to each file system) 
 One file system per device, one INODE table per file system. 
 Hierarchical structure: Some FCBs are just a list of pointers to other FCBs (i.e. indirection) 
 To work with a file (through the descriptor interface) the I-node of the file is brought into the 
main memory as an in-core INODE (V-Node).
INODE Table
INODE Structure
File System Directory Structure 
 The file system directory structure is a link between the INODE hash list and the directory files. 
 The root “/” INODE is always #2. The root “/” directory file data block is located thru INODE #2. 
 Directory file entries include each entry <filename, inode #>. Where filename is the local (unqualified) 
directory or regular filename within the directory and inode# is an index into the INODE hash array. 
 The (inode#) INODE in the hash list entry has pointer to the data block of the subsequent regular file or 
directory file data block. 
 If a directory file, the directory data blocks are read for the next <filename, inode #>, and the process 
repeats. 
 If a regular file, the data blocks are located and read. 
 This process also explains the difference between hard links and soft links. A hard link directory entry is 
a direct pointer to a file INODE. A soft link is a pointer to another directory entry. 
 In a link, rm clears the directory record. Usually means that the i-node number is set to 0 but the file may 
not be affected 
 The file i-node is only deleted when the last link to it is removed; the data block for the file is also deleted 
(reclaimed).
Hard links
Soft links
Example: Finding /usr/bin/vi 
 /usr/bin/vi => i-node of /usr/bin/vi 
 Get the root i-node: 
 The i-node number of ‘/’ is pre-defined (#2) 
 Use the root i-node to get to the ‘/’ data 
 Search (usr, i-node#) in the root’s data 
 Get the usr’s i-node 
 Get to the usr’s data and search for (bin, i-node#) 
 Get the bin’s i-node 
 Get to the bin’s data and search for (vi, i-node#) 
 Get the vi’s i-node, find data block 
 Permissions are checked all along the way 
 Each dir in the path must be (at least) executable
Finding /usr/bin/vi
File System Directory Structure
File System Data Structure 
disk drive 
partition partition partition 
file system 
super 
block 
boot 
block 
I-list 
Data blocks for files, dirs, etc. 
i-node i-node i-node . . . . . . . . . i-node
File System in More Detail 
Data Blocks 
i-list data data dir blk data dir blk 
i-node i-node i-node 
filename 
i-node 
number 
no 
: 
: 
: 
: 
no filename
Classical UNIX File System 
 Sequentially from a predefined disk addresses (cylinder 0, sector 0): 
– Boot block (Master Boot Record) 
– Superblock 
– I-node hash-array 
– Data blocks 
 Boot block: a hardware specific program that is called automatically to load UNIX 
at system startup time. 
 Super block -- it contains two lists: 
 a chain of free data block numbers 
 a chain of free i-node numbers
Superblock 
 One per filesystem 
 Contains: 
– Size of the file system; 
– The number of free blocks in the file system; 
– Size of the logical file block; 
– A list of free data blocks available for file allocation; 
– Index of the next free block on the list; 
– The size of I-node list; 
– The number of free I-nodes on the system; 
– The list of free INODES on the file system; 
– The index of the next free I-node on the list. 
 tune2fs –l /dev/sdax to display superblock info 
 df command output 
 sync command 
 du command
INODE Allocation 
 As long as there is a free I-node – allocate it. 
 Otherwise scan the I-node list linearly, and enter into the super-block list of free I-nodes 
as many numbers as possible. 
 Remember the highest free I-node number. 
 Continue with step 1. 
 Next time start scanning from the remembered Inode number; when at the end – go 
back to the beginning of the I-node list.
Data Block Allocation 
 Static and Contiguous Allocation (simple filesystem) 
- Allocates each file a fixed number of blocks at the creation time 
- Efficient offset lookup as only the block # of the offset 0 is needed 
- Inefficient space utilization, internal, external fragmentation 
- Fixed size, no support for dynamic extension 
 Block allocation (UNIX, DOS, Ext, Ext2, Ext3) 
-Assumes unstructured files as an array of bytes 
- Efficient offset -> disk block mapping 
- Efficient disk access for both sequential and random patterns by minimizing number of 
seeks due to sequential reads 
- Efficient space utilization, minimizing external/internal fragmentation 
 Extent allocation (FFS, NTFS, EXT4) 
- File get blocks in contiguous chunks called extents, multiple contiguous allocations 
- high performance for large files 
- larger block size = larger files
Static, Contiguous Allocation
Block Allocation in UNIX 
 Classic UNIX Block and DOS FAT Linked file systems 
 Extent-based allocation with a fixed extent size of one disk block. File blocks are scattered anywhere on 
the disk. Inefficient sequential access (i.e. fragmentation). 
 Dynamically expandable; accommodates large(r) file sizes better. 
 No external fragmentation 
 Optimized for small(er) files. Outdated empirical studies indicate that 98% of all files are under 80 KB 
 Poor performance for random access of large files 
 Wasted space in pointer blocks for large sparse files (indirection) 
 UNIX block allocation (see slide) 
- 10 direct pointers 
- 1 single indirect pointer: points to a block of N pointers to blocks 
- 1 double indirect pointer: points to a block of N pointers each of which points to a block of N 
pointers to blocks 
- 1 triple indirect pointer… 
- Overall addresses 10+N+N2+N3 disk blocks 
- N value determined by filesystem type. Determines maximum file size on a specific filesystem.
Block Allocation in UNIX
Extent-based, Multi-Block 
Allocation 
 Modern UNIX implementations use the multi-block, extent-based allocation for performance 
 File get blocks in contiguous chunks called extents. Multiple block with contiguous 
allocations. 
 For large files, B-tree is used for efficient offset lookup. 
 Efficient offset lookup and disk access. Uses newer “smart” disk sequential geometry (sector 
#) 
 Support for dynamic growth/shrink 
 Dynamic memory allocation techniques are used (e.g., first-fit) 
 Suffers from external fragmentation - use compaction
Extent-based allocation
DOS File Allocation Table (FAT) 
 A section at the beginning of the disk is set aside to contain the table 
 Indexed by the block numbers on disk 
 An entry for each disk block (or for a cluster thereof) 
 Blocks belonging to the same file are chained 
 The last file block, unused blocks and bad blocks have special markings 
 Each file is a linked list of disk blocks 
 Offset lookup: 
 Efficient for sequential access 
 Inefficient for random access 
 Access to large files may be inefficient as the blocks are scattered 
 Solution: block clustering 
 No fragmentation, wasted space for pointers in each block
DOS / FAT - 
Directory pointer and linked list block 
allocation
New UNIX File Support 
 Issues with the old UNIX file system – 
fragmentation, performance, reliability.. 
 BSD Fast File System (FFS) - BSD 
 Journaled File Systems (JFS) - AIX 
 Log-based file systems (LFS) – Various OS 
 Network File System (NFS) - Solaris

Contenu connexe

Tendances

Linux history & features
Linux history & featuresLinux history & features
Linux history & features
Rohit Kumar
 
Files concepts.53
Files concepts.53Files concepts.53
Files concepts.53
myrajendra
 
Network Attached Storage (NAS)
Network Attached Storage (NAS)Network Attached Storage (NAS)
Network Attached Storage (NAS)
sandeepgodfather
 
Management file and directory in linux
Management file and directory in linuxManagement file and directory in linux
Management file and directory in linux
Zkre Saleh
 
Linked allocation 48
Linked  allocation 48Linked  allocation 48
Linked allocation 48
myrajendra
 

Tendances (20)

File system
File systemFile system
File system
 
Linux history & features
Linux history & featuresLinux history & features
Linux history & features
 
Windows Kernel-
Windows Kernel-Windows Kernel-
Windows Kernel-
 
Protection and security of operating system
Protection and security of operating systemProtection and security of operating system
Protection and security of operating system
 
Free Space Management, Efficiency & Performance, Recovery and NFS
Free Space Management, Efficiency & Performance, Recovery and NFSFree Space Management, Efficiency & Performance, Recovery and NFS
Free Space Management, Efficiency & Performance, Recovery and NFS
 
Linux systems - Linux Commands and Shell Scripting
Linux systems - Linux Commands and Shell ScriptingLinux systems - Linux Commands and Shell Scripting
Linux systems - Linux Commands and Shell Scripting
 
Linux kernel
Linux kernelLinux kernel
Linux kernel
 
Linux file system
Linux file systemLinux file system
Linux file system
 
Network File System in Distributed Computing
Network File System in Distributed ComputingNetwork File System in Distributed Computing
Network File System in Distributed Computing
 
Topic # 12 of outline Configuring Local Services.pptx
Topic # 12 of outline Configuring Local Services.pptxTopic # 12 of outline Configuring Local Services.pptx
Topic # 12 of outline Configuring Local Services.pptx
 
Install and configure linux
Install and configure linuxInstall and configure linux
Install and configure linux
 
Files concepts.53
Files concepts.53Files concepts.53
Files concepts.53
 
Linux commands
Linux commandsLinux commands
Linux commands
 
Storage Virtualization
Storage VirtualizationStorage Virtualization
Storage Virtualization
 
Network Attached Storage (NAS)
Network Attached Storage (NAS)Network Attached Storage (NAS)
Network Attached Storage (NAS)
 
Linux seminar
Linux seminarLinux seminar
Linux seminar
 
Management file and directory in linux
Management file and directory in linuxManagement file and directory in linux
Management file and directory in linux
 
FAT vs NTFS
FAT vs NTFSFAT vs NTFS
FAT vs NTFS
 
introduction to system administration
introduction to system administrationintroduction to system administration
introduction to system administration
 
Linked allocation 48
Linked  allocation 48Linked  allocation 48
Linked allocation 48
 

En vedette

The unix file system
The unix file systemThe unix file system
The unix file system
gsandeepmenon
 

En vedette (20)

Unix File System
Unix File SystemUnix File System
Unix File System
 
Unix files
Unix filesUnix files
Unix files
 
Unix training session 1
Unix training   session 1Unix training   session 1
Unix training session 1
 
Flash! (Modern File Systems)
Flash! (Modern File Systems)Flash! (Modern File Systems)
Flash! (Modern File Systems)
 
Linux File System
Linux File SystemLinux File System
Linux File System
 
The unix file system
The unix file systemThe unix file system
The unix file system
 
Unit 2 ppt
Unit 2 pptUnit 2 ppt
Unit 2 ppt
 
Operating Systems (printouts)
Operating Systems (printouts)Operating Systems (printouts)
Operating Systems (printouts)
 
Nu: scrum op school
Nu: scrum op schoolNu: scrum op school
Nu: scrum op school
 
Unix ch03-03(2)
Unix ch03-03(2)Unix ch03-03(2)
Unix ch03-03(2)
 
Inode explanation
Inode explanationInode explanation
Inode explanation
 
Monolithic kernel
Monolithic kernelMonolithic kernel
Monolithic kernel
 
Basis Linux (aan de hand van LPIC-1)
Basis Linux (aan de hand van LPIC-1)Basis Linux (aan de hand van LPIC-1)
Basis Linux (aan de hand van LPIC-1)
 
How inodes Work
How inodes WorkHow inodes Work
How inodes Work
 
Monolithic kernel vs. Microkernel
Monolithic kernel vs. MicrokernelMonolithic kernel vs. Microkernel
Monolithic kernel vs. Microkernel
 
Ch2
Ch2Ch2
Ch2
 
Operating system kernal
Operating system kernalOperating system kernal
Operating system kernal
 
KERNAL ARCHITECTURE
KERNAL ARCHITECTUREKERNAL ARCHITECTURE
KERNAL ARCHITECTURE
 
Building Linux IPv6 DNS Server (Complete Presentation)
Building Linux IPv6 DNS Server (Complete Presentation)Building Linux IPv6 DNS Server (Complete Presentation)
Building Linux IPv6 DNS Server (Complete Presentation)
 
Mca ii os u-5 unix linux file system
Mca  ii  os u-5 unix linux file systemMca  ii  os u-5 unix linux file system
Mca ii os u-5 unix linux file system
 

Similaire à Unix file systems 2 in unix internal systems

File management
File managementFile management
File management
Mohd Arif
 
Ch12 OS
Ch12 OSCh12 OS
Ch12 OS
C.U
 
Unit 7
Unit 7Unit 7
Unit 7
siddr
 
Distributed File System
Distributed File SystemDistributed File System
Distributed File System
Ntu
 

Similaire à Unix file systems 2 in unix internal systems (20)

Internal representation of file chapter 4 Sowmya Jyothi
Internal representation of file chapter 4 Sowmya JyothiInternal representation of file chapter 4 Sowmya Jyothi
Internal representation of file chapter 4 Sowmya Jyothi
 
Internal representation of files ppt
Internal representation of files pptInternal representation of files ppt
Internal representation of files ppt
 
Ch11
Ch11Ch11
Ch11
 
file management_part2_os_notes.ppt
file management_part2_os_notes.pptfile management_part2_os_notes.ppt
file management_part2_os_notes.ppt
 
File management
File managementFile management
File management
 
Root file system
Root file systemRoot file system
Root file system
 
OSCh12
OSCh12OSCh12
OSCh12
 
Ch12 OS
Ch12 OSCh12 OS
Ch12 OS
 
OS_Ch12
OS_Ch12OS_Ch12
OS_Ch12
 
Unix Administration
Unix AdministrationUnix Administration
Unix Administration
 
Operating Systems - Implementing File Systems
Operating Systems - Implementing File SystemsOperating Systems - Implementing File Systems
Operating Systems - Implementing File Systems
 
File systemimplementationfinal
File systemimplementationfinalFile systemimplementationfinal
File systemimplementationfinal
 
File system interfacefinal
File system interfacefinalFile system interfacefinal
File system interfacefinal
 
Glusterfs session #1 disk filesystems
Glusterfs session #1   disk filesystemsGlusterfs session #1   disk filesystems
Glusterfs session #1 disk filesystems
 
Windowsforensics
WindowsforensicsWindowsforensics
Windowsforensics
 
009709863.pdf
009709863.pdf009709863.pdf
009709863.pdf
 
Filesystemimplementationpre final-160919095849
Filesystemimplementationpre final-160919095849Filesystemimplementationpre final-160919095849
Filesystemimplementationpre final-160919095849
 
Chapter 11 - File System Implementation
Chapter 11 - File System ImplementationChapter 11 - File System Implementation
Chapter 11 - File System Implementation
 
Unit 7
Unit 7Unit 7
Unit 7
 
Distributed File System
Distributed File SystemDistributed File System
Distributed File System
 

Dernier

Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Victor Rentea
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Safe Software
 
Architecting Cloud Native Applications
Architecting Cloud Native ApplicationsArchitecting Cloud Native Applications
Architecting Cloud Native Applications
WSO2
 
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
?#DUbAI#??##{{(☎️+971_581248768%)**%*]'#abortion pills for sale in dubai@
 

Dernier (20)

Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024Finding Java's Hidden Performance Traps @ DevoxxUK 2024
Finding Java's Hidden Performance Traps @ DevoxxUK 2024
 
Mcleodganj Call Girls 🥰 8617370543 Service Offer VIP Hot Model
Mcleodganj Call Girls 🥰 8617370543 Service Offer VIP Hot ModelMcleodganj Call Girls 🥰 8617370543 Service Offer VIP Hot Model
Mcleodganj Call Girls 🥰 8617370543 Service Offer VIP Hot Model
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 
DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
DEV meet-up UiPath Document Understanding May 7 2024 AmsterdamDEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
DEV meet-up UiPath Document Understanding May 7 2024 Amsterdam
 
Architecting Cloud Native Applications
Architecting Cloud Native ApplicationsArchitecting Cloud Native Applications
Architecting Cloud Native Applications
 
Introduction to Multilingual Retrieval Augmented Generation (RAG)
Introduction to Multilingual Retrieval Augmented Generation (RAG)Introduction to Multilingual Retrieval Augmented Generation (RAG)
Introduction to Multilingual Retrieval Augmented Generation (RAG)
 
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, AdobeApidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
 
Apidays New York 2024 - The value of a flexible API Management solution for O...
Apidays New York 2024 - The value of a flexible API Management solution for O...Apidays New York 2024 - The value of a flexible API Management solution for O...
Apidays New York 2024 - The value of a flexible API Management solution for O...
 
Vector Search -An Introduction in Oracle Database 23ai.pptx
Vector Search -An Introduction in Oracle Database 23ai.pptxVector Search -An Introduction in Oracle Database 23ai.pptx
Vector Search -An Introduction in Oracle Database 23ai.pptx
 
"I see eyes in my soup": How Delivery Hero implemented the safety system for ...
"I see eyes in my soup": How Delivery Hero implemented the safety system for ..."I see eyes in my soup": How Delivery Hero implemented the safety system for ...
"I see eyes in my soup": How Delivery Hero implemented the safety system for ...
 
Exploring Multimodal Embeddings with Milvus
Exploring Multimodal Embeddings with MilvusExploring Multimodal Embeddings with Milvus
Exploring Multimodal Embeddings with Milvus
 
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
+971581248768>> SAFE AND ORIGINAL ABORTION PILLS FOR SALE IN DUBAI AND ABUDHA...
 
TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
TrustArc Webinar - Unlock the Power of AI-Driven Data DiscoveryTrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
 
ICT role in 21st century education and its challenges
ICT role in 21st century education and its challengesICT role in 21st century education and its challenges
ICT role in 21st century education and its challenges
 
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost SavingRepurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
 
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWEREMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
EMPOWERMENT TECHNOLOGY GRADE 11 QUARTER 2 REVIEWER
 
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemkeProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
 
Strategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a FresherStrategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a Fresher
 
FWD Group - Insurer Innovation Award 2024
FWD Group - Insurer Innovation Award 2024FWD Group - Insurer Innovation Award 2024
FWD Group - Insurer Innovation Award 2024
 
AWS Community Day CPH - Three problems of Terraform
AWS Community Day CPH - Three problems of TerraformAWS Community Day CPH - Three problems of Terraform
AWS Community Day CPH - Three problems of Terraform
 

Unix file systems 2 in unix internal systems

  • 1. How UNIX Organizes and Accesses Files on Disk
  • 2. Why File Systems  File system is a service which supports an abstract representation of the secondary storage to the OS  A file system organizes data logically for random access by the OS.  A virtual file system provides the interface between the data representation by the kernel to the user process and the data presentation to the kernel in memory. The file and directory system cache.  Because of the performance disparity between disk and CPU/memory, file system performance is the paramount issue for any OS
  • 3. Main memory vs. Secondary storage  Small (MB/GB)  Expensive  Fast (10-6/10-7 sec)  Volatile  Directly accessible by CPU Interface: (virtual) memory address  Large (GB/TB)  Cheap  Slow (10-2/10-3 sec)  Persistent  Cannot be directly accessed by CPU – Data should be first brought into the main memory
  • 4. Secondary storage (disk)  A number of disks directly attached to the computer  Network attached disks accessible through a fast network - Storage Area Network (SAN)  Simple disks (IDE, SATA) have a described disk geometry. Sector size is the minimum read/write unit of data (usually 512Bytes)  Access: (#surface, #track, #sector)  Smart disks (SCSI, SAN, NAS) hide the internal disk layout using a controller type function  Access: (#sector)  Moving arm assembly (Seek) is expensive  Sequential access is x100 times faster than the random access
  • 5. Internal disk structure  Disk structure
  • 6. User Process Accessing Data  Given the file name. Get to the file’s FCB using the file system catalog (Open, Close, Set_Attribute)  The catalog maps a file name to the FCB  Checks permissions  file_handle=open(file_name):  search the catalog and bring FCB into the memory  UNIX: in-memory FCB: in-core i-node  Use the FCB to get to the desired offset within the file data: (CREATE, DELETE, SEEK, TRUNCATE)  close(file_handle): release FCB from memory
  • 7. Catalog Organization (Directories)  In UNIX, special files (not special device files) called directories contain information about other files. A UNIX directory is a file whose data is an array or list of (filename, i-node#) pairs.  it has an owner, group owner, size, access permissions, etc.  many file operations can be used on directories  As a file, a directory has an I-node type structure.  A flag in the structure indicates its type.  Unlike other files, the kernel imposes a structure on directory files using mkdir.  A directory is a sequence of lines , a sequence of directory entries of variable length where each line contains an i-node number and a file name mapping: <filename, inode #>  Directory data is stored as binary, cannot use cat. But some older UNIXs allow: od -c dir-name.  Although directories are files, UNIX permissions – rwx- have slightly different meanings: - r, lists directoy contents - w, add a file to the directory - x, cd to the directory
  • 8. Subdirectories  mkdir subdir causes:  the creation of a subdir directory file and an i-node for it  an i-node number and name are added to the parent directory file 120 207 135 “fred.html” “abc” “bookmark.c” 201 “subdir” • “.” and “..” are stored as ordinary file names with i-node numbers pointing to the correct directory files. ben book memos
  • 9. Subdirectories in more detail: Directory ben 123 247 260 “.” “..” “book” 401 “memos” Directory book 260 123 566 “.” “..” “chap1” 567 “chap2” 590 “chap3” Directory memos 401 123 800 “.” “..” “kh” 810 077 “kd” 590 “mw”
  • 10. Directory block or chunk  Directories are allocated in chunks. Each chunk can be read/written in a single I/O operation, Why? Performance.
  • 11. Regular Files and I-nodes  Information about each regular local file is contained in a structure called an INODE. Containing the file FCB information.  There is 1-to-1 mapping between the INODE and a file. However a file may have multiple INODES. Large files may in fact multiple layers of INODE’s using indirection to keep track of data blocks.  Each INODE is identified through its number, a non-negative integer as an index into -  The INODE hash array is a list of allocated INODE‘s located at the beginning of the file system  INODE structures (UNIX i-node list) are stored on the file system block device (e.g., disk) in a predefined location on the disk. UNIX: the i-node list. Where it is exactly is file system implementation specific.  INODE numbers have only local meaning (to each file system)  One file system per device, one INODE table per file system.  Hierarchical structure: Some FCBs are just a list of pointers to other FCBs (i.e. indirection)  To work with a file (through the descriptor interface) the I-node of the file is brought into the main memory as an in-core INODE (V-Node).
  • 14. File System Directory Structure  The file system directory structure is a link between the INODE hash list and the directory files.  The root “/” INODE is always #2. The root “/” directory file data block is located thru INODE #2.  Directory file entries include each entry <filename, inode #>. Where filename is the local (unqualified) directory or regular filename within the directory and inode# is an index into the INODE hash array.  The (inode#) INODE in the hash list entry has pointer to the data block of the subsequent regular file or directory file data block.  If a directory file, the directory data blocks are read for the next <filename, inode #>, and the process repeats.  If a regular file, the data blocks are located and read.  This process also explains the difference between hard links and soft links. A hard link directory entry is a direct pointer to a file INODE. A soft link is a pointer to another directory entry.  In a link, rm clears the directory record. Usually means that the i-node number is set to 0 but the file may not be affected  The file i-node is only deleted when the last link to it is removed; the data block for the file is also deleted (reclaimed).
  • 17. Example: Finding /usr/bin/vi  /usr/bin/vi => i-node of /usr/bin/vi  Get the root i-node:  The i-node number of ‘/’ is pre-defined (#2)  Use the root i-node to get to the ‘/’ data  Search (usr, i-node#) in the root’s data  Get the usr’s i-node  Get to the usr’s data and search for (bin, i-node#)  Get the bin’s i-node  Get to the bin’s data and search for (vi, i-node#)  Get the vi’s i-node, find data block  Permissions are checked all along the way  Each dir in the path must be (at least) executable
  • 20. File System Data Structure disk drive partition partition partition file system super block boot block I-list Data blocks for files, dirs, etc. i-node i-node i-node . . . . . . . . . i-node
  • 21. File System in More Detail Data Blocks i-list data data dir blk data dir blk i-node i-node i-node filename i-node number no : : : : no filename
  • 22. Classical UNIX File System  Sequentially from a predefined disk addresses (cylinder 0, sector 0): – Boot block (Master Boot Record) – Superblock – I-node hash-array – Data blocks  Boot block: a hardware specific program that is called automatically to load UNIX at system startup time.  Super block -- it contains two lists:  a chain of free data block numbers  a chain of free i-node numbers
  • 23. Superblock  One per filesystem  Contains: – Size of the file system; – The number of free blocks in the file system; – Size of the logical file block; – A list of free data blocks available for file allocation; – Index of the next free block on the list; – The size of I-node list; – The number of free I-nodes on the system; – The list of free INODES on the file system; – The index of the next free I-node on the list.  tune2fs –l /dev/sdax to display superblock info  df command output  sync command  du command
  • 24. INODE Allocation  As long as there is a free I-node – allocate it.  Otherwise scan the I-node list linearly, and enter into the super-block list of free I-nodes as many numbers as possible.  Remember the highest free I-node number.  Continue with step 1.  Next time start scanning from the remembered Inode number; when at the end – go back to the beginning of the I-node list.
  • 25. Data Block Allocation  Static and Contiguous Allocation (simple filesystem) - Allocates each file a fixed number of blocks at the creation time - Efficient offset lookup as only the block # of the offset 0 is needed - Inefficient space utilization, internal, external fragmentation - Fixed size, no support for dynamic extension  Block allocation (UNIX, DOS, Ext, Ext2, Ext3) -Assumes unstructured files as an array of bytes - Efficient offset -> disk block mapping - Efficient disk access for both sequential and random patterns by minimizing number of seeks due to sequential reads - Efficient space utilization, minimizing external/internal fragmentation  Extent allocation (FFS, NTFS, EXT4) - File get blocks in contiguous chunks called extents, multiple contiguous allocations - high performance for large files - larger block size = larger files
  • 27. Block Allocation in UNIX  Classic UNIX Block and DOS FAT Linked file systems  Extent-based allocation with a fixed extent size of one disk block. File blocks are scattered anywhere on the disk. Inefficient sequential access (i.e. fragmentation).  Dynamically expandable; accommodates large(r) file sizes better.  No external fragmentation  Optimized for small(er) files. Outdated empirical studies indicate that 98% of all files are under 80 KB  Poor performance for random access of large files  Wasted space in pointer blocks for large sparse files (indirection)  UNIX block allocation (see slide) - 10 direct pointers - 1 single indirect pointer: points to a block of N pointers to blocks - 1 double indirect pointer: points to a block of N pointers each of which points to a block of N pointers to blocks - 1 triple indirect pointer… - Overall addresses 10+N+N2+N3 disk blocks - N value determined by filesystem type. Determines maximum file size on a specific filesystem.
  • 29. Extent-based, Multi-Block Allocation  Modern UNIX implementations use the multi-block, extent-based allocation for performance  File get blocks in contiguous chunks called extents. Multiple block with contiguous allocations.  For large files, B-tree is used for efficient offset lookup.  Efficient offset lookup and disk access. Uses newer “smart” disk sequential geometry (sector #)  Support for dynamic growth/shrink  Dynamic memory allocation techniques are used (e.g., first-fit)  Suffers from external fragmentation - use compaction
  • 31. DOS File Allocation Table (FAT)  A section at the beginning of the disk is set aside to contain the table  Indexed by the block numbers on disk  An entry for each disk block (or for a cluster thereof)  Blocks belonging to the same file are chained  The last file block, unused blocks and bad blocks have special markings  Each file is a linked list of disk blocks  Offset lookup:  Efficient for sequential access  Inefficient for random access  Access to large files may be inefficient as the blocks are scattered  Solution: block clustering  No fragmentation, wasted space for pointers in each block
  • 32. DOS / FAT - Directory pointer and linked list block allocation
  • 33. New UNIX File Support  Issues with the old UNIX file system – fragmentation, performance, reliability..  BSD Fast File System (FFS) - BSD  Journaled File Systems (JFS) - AIX  Log-based file systems (LFS) – Various OS  Network File System (NFS) - Solaris