This document provides a summary of file system concepts in the xv6 operating system, including:
1) Inodes are data structures that represent files and provide metadata and pointers to file data blocks. On-disk inodes are read into memory inodes when files are accessed.
2) Directories are represented by special directory inodes containing directory entries with names and pointers to other inodes.
3) The file system layout divides the disk into sections for the boot sector, superblock, inodes, bitmap, data blocks, and log for atomic transactions.
A fast file system for unix presentation by parang saraf (cs5204 VT)Parang Saraf
This is the presentation of the paper "A fast file system for unix"
In case if you need a copy of these slides feel free to contact me at parang[DOT]saraf[AT]gmail
A fast file system for unix presentation by parang saraf (cs5204 VT)Parang Saraf
This is the presentation of the paper "A fast file system for unix"
In case if you need a copy of these slides feel free to contact me at parang[DOT]saraf[AT]gmail
Course 102: Lecture 26: FileSystems in Linux (Part 1) Ahmed El-Arabawy
This lecture introduces some concepts about FileSystems in Linux.
Video for this lecture on youtube:
http://www.youtube.com/watch?v=9jj1QOokACo
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
Part 03 File System Implementation in LinuxTushar B Kute
Presentation on "Virtual File System Implementation in Linux".
Presented at Army Institute of Technology, Pune for FDP on "Basics of Linux Kernel Programming". by Tushar B Kute (http://tusharkute.com).
This lecture describes the virtual filesystems procfs and sysfs.
Video for this Lecture on youtube:
http://www.youtube.com/watch?v=wlxL-iQN6No
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
This lecture discusses the concept of Multi-User support in Linux. It discusses how Linux protects user files and resources from other user unauthorized access. It also shows how to share resources and files among users, how to add/del users and groups.
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
- https://www.linkedin.com/in/ahmedelarabawy
This lecture covers the handling of files and file management commands by Linux Subsystems. It also covers creating both Hard Links and Symbolic Links
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
- https://www.linkedin.com/in/ahmedelarabawy
Course 102: Lecture 24: Archiving and Compression of Files Ahmed El-Arabawy
This lecture discusses the different commands and utilities used for archiving and compression of files and directories in Linux
Video for this lecture on youtube:
http://www.youtube.com/watch?v=R6ZQ6PJyy28
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
The Linux Kernel Implementation of Pipes and FIFOsDivye Kapoor
A walkthrough of the code structure used in the linux kernel to implement pipes and FIFOs.
This was presented to a Senior level class at the Indian Institute of Technology, Roorkee.
Course 102: Lecture 26: FileSystems in Linux (Part 1) Ahmed El-Arabawy
This lecture introduces some concepts about FileSystems in Linux.
Video for this lecture on youtube:
http://www.youtube.com/watch?v=9jj1QOokACo
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
Part 03 File System Implementation in LinuxTushar B Kute
Presentation on "Virtual File System Implementation in Linux".
Presented at Army Institute of Technology, Pune for FDP on "Basics of Linux Kernel Programming". by Tushar B Kute (http://tusharkute.com).
This lecture describes the virtual filesystems procfs and sysfs.
Video for this Lecture on youtube:
http://www.youtube.com/watch?v=wlxL-iQN6No
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
This lecture discusses the concept of Multi-User support in Linux. It discusses how Linux protects user files and resources from other user unauthorized access. It also shows how to share resources and files among users, how to add/del users and groups.
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
- https://www.linkedin.com/in/ahmedelarabawy
This lecture covers the handling of files and file management commands by Linux Subsystems. It also covers creating both Hard Links and Symbolic Links
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
- https://www.linkedin.com/in/ahmedelarabawy
Course 102: Lecture 24: Archiving and Compression of Files Ahmed El-Arabawy
This lecture discusses the different commands and utilities used for archiving and compression of files and directories in Linux
Video for this lecture on youtube:
http://www.youtube.com/watch?v=R6ZQ6PJyy28
Check the other Lectures and courses in
http://Linux4EnbeddedSystems.com
or Follow our Facebook Group at
- Facebook: @LinuxforEmbeddedSystems
Lecturer Profile:
Ahmed ElArabawy
- https://www.linkedin.com/in/ahmedelarabawy
The Linux Kernel Implementation of Pipes and FIFOsDivye Kapoor
A walkthrough of the code structure used in the linux kernel to implement pipes and FIFOs.
This was presented to a Senior level class at the Indian Institute of Technology, Roorkee.
this contain inforamation about operating system subject.it is very useful information for the students those who are persuing B.tech graduates .it contains several ppts which are useful for the students not only for them but also faculty those who are working in engineering colleges
A presentation on the Ext4 file system and the evolution of Ext filesystem in Linux operating system. Linux uses virtual filesystem. The comparison of the ext filesystem generations is provided.
CNIT 121: 13 Investigating Mac OS X SystemsSam Bowne
Slides for a college course based on "Incident Response & Computer Forensics, Third Edition" by by Jason Luttgens, Matthew Pepe, and Kevin Mandia.
Teacher: Sam Bowne
Twitter: @sambowne
Website: https://samsclass.info/121/121_F16.shtml
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
A tale of scale & speed: How the US Navy is enabling software delivery from l...sonjaschweigert1
Rapid and secure feature delivery is a goal across every application team and every branch of the DoD. The Navy’s DevSecOps platform, Party Barge, has achieved:
- Reduction in onboarding time from 5 weeks to 1 day
- Improved developer experience and productivity through actionable findings and reduction of false positives
- Maintenance of superior security standards and inherent policy enforcement with Authorization to Operate (ATO)
Development teams can ship efficiently and ensure applications are cyber ready for Navy Authorizing Officials (AOs). In this webinar, Sigma Defense and Anchore will give attendees a look behind the scenes and demo secure pipeline automation and security artifacts that speed up application ATO and time to production.
We will cover:
- How to remove silos in DevSecOps
- How to build efficient development pipeline roles and component templates
- How to deliver security artifacts that matter for ATO’s (SBOMs, vulnerability reports, and policy evidence)
- How to streamline operations with automated policy checks on container images
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
State of ICS and IoT Cyber Threat Landscape Report 2024 previewPrayukth K V
The IoT and OT threat landscape report has been prepared by the Threat Research Team at Sectrio using data from Sectrio, cyber threat intelligence farming facilities spread across over 85 cities around the world. In addition, Sectrio also runs AI-based advanced threat and payload engagement facilities that serve as sinks to attract and engage sophisticated threat actors, and newer malware including new variants and latent threats that are at an earlier stage of development.
The latest edition of the OT/ICS and IoT security Threat Landscape Report 2024 also covers:
State of global ICS asset and network exposure
Sectoral targets and attacks as well as the cost of ransom
Global APT activity, AI usage, actor and tactic profiles, and implications
Rise in volumes of AI-powered cyberattacks
Major cyber events in 2024
Malware and malicious payload trends
Cyberattack types and targets
Vulnerability exploit attempts on CVEs
Attacks on counties – USA
Expansion of bot farms – how, where, and why
In-depth analysis of the cyber threat landscape across North America, South America, Europe, APAC, and the Middle East
Why are attacks on smart factories rising?
Cyber risk predictions
Axis of attacks – Europe
Systemic attacks in the Middle East
Download the full report from here:
https://sectrio.com/resources/ot-threat-landscape-reports/sectrio-releases-ot-ics-and-iot-security-threat-landscape-report-2024/
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Empowering NextGen Mobility via Large Action Model Infrastructure (LAMI): pav...
AOS Lab 10: File system -- Inodes and beyond
1. Lab 10: File system – Inodes and beyond
Advanced Operating Systems
Zubair Nabi
zubair.nabi@itu.edu.pk
April 10, 2013
2. Recap of Lab 9: xv6 FS layers
File descriptors
System calls
Recursive lookup Pathnames
Directory inodes
Inodes and
block allocator
Logging
Buffer cache
Directories
Files
Transactions
Blocks
3. Recap of Lab 9: xv6 FS layers (2)
1
Buffer cache: Reads and writes blocks on the IDE disk via the
buffer cache, which synchronizes access to disk blocks
4. Recap of Lab 9: xv6 FS layers (2)
1
Buffer cache: Reads and writes blocks on the IDE disk via the
buffer cache, which synchronizes access to disk blocks
• Ensures that only one kernel process can edit any particular block
at a time
5. Recap of Lab 9: xv6 FS layers (2)
1
Buffer cache: Reads and writes blocks on the IDE disk via the
buffer cache, which synchronizes access to disk blocks
• Ensures that only one kernel process can edit any particular block
at a time
2
Logging: Ensures atomicity by enabling higher layers to wrap
updates to several blocks in a transaction
6. Recap of Lab 9: xv6 FS layers (2)
1
Buffer cache: Reads and writes blocks on the IDE disk via the
buffer cache, which synchronizes access to disk blocks
• Ensures that only one kernel process can edit any particular block
at a time
2
Logging: Ensures atomicity by enabling higher layers to wrap
updates to several blocks in a transaction
3
Inodes and block allocator: Provides unnamed files, each
unnamed file is represented by an inode and a sequence of
blocks holding the file content
7. Recap of Lab 9: xv6 FS layers (3)
4
Directory inodes: Implements directories as a special kind of
inode
8. Recap of Lab 9: xv6 FS layers (3)
4
Directory inodes: Implements directories as a special kind of
inode
• The content of this inode is a sequence of directory entries, each
of which contains a name and a reference to the named file’s
inode
9. Recap of Lab 9: xv6 FS layers (3)
4
Directory inodes: Implements directories as a special kind of
inode
• The content of this inode is a sequence of directory entries, each
of which contains a name and a reference to the named file’s
inode
5
Recursive lookup: Provides hierarchical path names such as
/foo/bar/baz.txt, via recursive lookup
10. Recap of Lab 9: xv6 FS layers (3)
4
Directory inodes: Implements directories as a special kind of
inode
• The content of this inode is a sequence of directory entries, each
of which contains a name and a reference to the named file’s
inode
5
Recursive lookup: Provides hierarchical path names such as
/foo/bar/baz.txt, via recursive lookup
6
File descriptors: Abstracts many Unix resources, such as pipes,
devices, file, etc., using the file system interface
11. Recap of Lab 9: File system layout
• xv6 lays out inodes and content blocks on the disk by dividing the
disk into several sections
12. Recap of Lab 9: File system layout
• xv6 lays out inodes and content blocks on the disk by dividing the
disk into several sections
boot super
0
1
inodes...
2
• Block 0 holds the boot sector
bitmap...
…..
data...
log...
13. Recap of Lab 9: File system layout
• xv6 lays out inodes and content blocks on the disk by dividing the
disk into several sections
boot super
0
1
inodes...
2
bitmap...
data...
log...
…..
• Block 0 holds the boot sector
• Block 1 (called the superblock) contains metadata about the file
system
14. Recap of Lab 9: File system layout
• xv6 lays out inodes and content blocks on the disk by dividing the
disk into several sections
boot super
0
1
inodes...
2
bitmap...
data...
log...
…..
• Block 0 holds the boot sector
• Block 1 (called the superblock) contains metadata about the file
system
• File system size in blocks, the number of data blocks, the number
of inodes, and the number of blocks in the log
15. Recap of Lab 9: File system layout
• xv6 lays out inodes and content blocks on the disk by dividing the
disk into several sections
boot super
0
1
inodes...
2
bitmap...
data...
log...
…..
• Block 0 holds the boot sector
• Block 1 (called the superblock) contains metadata about the file
system
• File system size in blocks, the number of data blocks, the number
of inodes, and the number of blocks in the log
• Blocks starting at 2 hold inodes, with multiple inodes per block
16. Recap of Lab 9: File system layout
boot super
0
1
inodes...
2
bitmap...
data...
log...
…..
• inode blocks are followed by bitmap blocks which keep track of
data blocks in use
17. Recap of Lab 9: File system layout
boot super
0
1
inodes...
2
bitmap...
data...
log...
…..
• inode blocks are followed by bitmap blocks which keep track of
data blocks in use
• Bitmap blocks are followed by data blocks which hold file and
directory contents
18. Recap of Lab 9: File system layout
boot super
0
1
inodes...
2
bitmap...
data...
log...
…..
• inode blocks are followed by bitmap blocks which keep track of
data blocks in use
• Bitmap blocks are followed by data blocks which hold file and
directory contents
• Finally at the end, the blocks hold a log which is required by the
transaction layer
19. Inodes
• Have two variants:
1
On-disk data structure containing a file’s size and list of data block
numbers
20. Inodes
• Have two variants:
On-disk data structure containing a file’s size and list of data block
numbers
2 In-memory version of the on-disk inode, along with extra
information needed within the kernel
1
21. Inodes
• Have two variants:
On-disk data structure containing a file’s size and list of data block
numbers
2 In-memory version of the on-disk inode, along with extra
information needed within the kernel
1
• All on-disk inodes are stored in a contiguous area of disk,
between the superblock and the bitmap block
22. Inodes
• Have two variants:
On-disk data structure containing a file’s size and list of data block
numbers
2 In-memory version of the on-disk inode, along with extra
information needed within the kernel
1
• All on-disk inodes are stored in a contiguous area of disk,
between the superblock and the bitmap block
• Each inode has the same size, so given a number n (called the
inode number or i-number), it is simple to locate the
corresponding inode
24. On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, and
special files (devices)
25. On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, and
special files (devices)
• Zero indicates that the dinode is free
26. On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, and
special files (devices)
• Zero indicates that the dinode is free
• Also keeps track of the number of directory entries that refer to
this inode
27. On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, and
special files (devices)
• Zero indicates that the dinode is free
• Also keeps track of the number of directory entries that refer to
this inode
• This reference count dictates when the inode should be freed
28. On-disk inodes
• Represented by struct dinode
• Contains a type field to distinguish between files, directories, and
special files (devices)
• Zero indicates that the dinode is free
• Also keeps track of the number of directory entries that refer to
this inode
• This reference count dictates when the inode should be freed
• Also has fields to hold number of bytes of content and the block
numbers of disk blocks
29. Code: dinode
struct dinode {
short type; // File type
short major; // Major device number (T_DEV only)
short minor; // Minor device number (T_DEV only)
short nlink; // Number of links to inode in file s
uint size; // Size of file (bytes)
uint addrs[NDIRECT+1]; // Data block addresses
};
#define T_DIR 1 // Directory
#define T_FILE 2 // File
#define T_DEV 3 // Device
32. In-memory inodes
• Represented by struct inode
• An inode is kept in memory if there are C pointers referring to it
• These pointers come from file descriptors, current working
directories, and kernel code
33. In-memory inodes
• Represented by struct inode
• An inode is kept in memory if there are C pointers referring to it
• These pointers come from file descriptors, current working
directories, and kernel code
• iget and iput functions are used to acquire and release
pointers to/from an inode
34. In-memory inodes
• Represented by struct inode
• An inode is kept in memory if there are C pointers referring to it
• These pointers come from file descriptors, current working
directories, and kernel code
• iget and iput functions are used to acquire and release
pointers to/from an inode
• A pointer via an iget() call implements a weak form of a lock by
ensuring that the inode will stay in the cache till the reference
count goes down to zero
35. In-memory inodes
• Represented by struct inode
• An inode is kept in memory if there are C pointers referring to it
• These pointers come from file descriptors, current working
directories, and kernel code
• iget and iput functions are used to acquire and release
pointers to/from an inode
• A pointer via an iget() call implements a weak form of a lock by
ensuring that the inode will stay in the cache till the reference
count goes down to zero
• These pointers enable long-term references (open files and
current directory) and to prevent deadlock in code that
manipulates multiple inodes (pathname lookup)
36. Code: inode
struct inode {
uint dev; // Device number
uint inum; // Inode number
int ref; // Reference count
int flags; // I_BUSY, I_VALID
short type; // copy of disk inode
short major;
short minor;
short nlink;
uint size;
uint addrs[NDIRECT+1];
};
#define I_BUSY 0x1
#define I_VALID 0x2
37. Inode locks and allocation
• To ensure that an inode has valid content, the code must read it
from disk
38. Inode locks and allocation
• To ensure that an inode has valid content, the code must read it
from disk
• This read call must be wrapped around ilock and iunlock
39. Inode locks and allocation
• To ensure that an inode has valid content, the code must read it
from disk
• This read call must be wrapped around ilock and iunlock
• This allows multiple processes to hold a C pointer to an inode but
only one process can lock it at a time
40. Inode locks and allocation
• To ensure that an inode has valid content, the code must read it
from disk
• This read call must be wrapped around ilock and iunlock
• This allows multiple processes to hold a C pointer to an inode but
only one process can lock it at a time
• Inodes are allocated via ialloc which works similar to balloc
41. Inode data
• Data is found in the blocks pointed to by the addrs fields
42. Inode data
• Data is found in the blocks pointed to by the addrs fields
• Size of addrs is NDIRECT+1 where NDIRECT is 12
43. Inode data
• Data is found in the blocks pointed to by the addrs fields
• Size of addrs is NDIRECT+1 where NDIRECT is 12
• addrs can refer to 6KB of data
44. Inode data
• Data is found in the blocks pointed to by the addrs fields
• Size of addrs is NDIRECT+1 where NDIRECT is 12
• addrs can refer to 6KB of data
• The 13th location in addrs field points to the indirect block
(NINDIRECT) which points to 64KB of data
45. Inode data
• Data is found in the blocks pointed to by the addrs fields
• Size of addrs is NDIRECT+1 where NDIRECT is 12
• addrs can refer to 6KB of data
• The 13th location in addrs field points to the indirect block
(NINDIRECT) which points to 64KB of data
• Therefore, while fixed-sized blocks simplify look up, the maximum
size of a file in xv6 can be 70KB
46. Inodes content
• bmap(struct inode *ip, uint bn) returns the disk
address of the nth block within inode ip, masking away the
complexity of direct and indirect blocks
47. Inodes content
• bmap(struct inode *ip, uint bn) returns the disk
address of the nth block within inode ip, masking away the
complexity of direct and indirect blocks
• If the data block does not exist, it is created
48. Inodes content
• bmap(struct inode *ip, uint bn) returns the disk
address of the nth block within inode ip, masking away the
complexity of direct and indirect blocks
• If the data block does not exist, it is created
• itrunc(struct inode *ip) frees inode ip by setting its
reference count to zero and freeing up blocks, both direct and
indirect
49. Inodes content
• bmap(struct inode *ip, uint bn) returns the disk
address of the nth block within inode ip, masking away the
complexity of direct and indirect blocks
• If the data block does not exist, it is created
• itrunc(struct inode *ip) frees inode ip by setting its
reference count to zero and freeing up blocks, both direct and
indirect
• readi(struct inode *ip, char *dst, uint
off, uint n) reads n blocks in inode ip starting from off
into dst
50. Inodes content (2)
• writei(struct inode *ip, char *src, uint
off, uint n) works similar to readi but it:
51. Inodes content (2)
• writei(struct inode *ip, char *src, uint
off, uint n) works similar to readi but it:
1
Copies data in instead of out
52. Inodes content (2)
• writei(struct inode *ip, char *src, uint
off, uint n) works similar to readi but it:
1
2
Copies data in instead of out
Extends the file if the write increases its size
53. Inodes content (2)
• writei(struct inode *ip, char *src, uint
off, uint n) works similar to readi but it:
Copies data in instead of out
Extends the file if the write increases its size
3 Updates the size in the inode
1
2
54. Inodes content (2)
• writei(struct inode *ip, char *src, uint
off, uint n) works similar to readi but it:
Copies data in instead of out
Extends the file if the write increases its size
3 Updates the size in the inode
1
2
• stati(struct inode *ip, struct stat *st)
copies metadata of inode ip into st which is exposed to
userspace via the stat system call
55. Directory layer
• A directory is a file with an inode type T_DIR and data in the
form of a sequence of directory entries
56. Directory layer
• A directory is a file with an inode type T_DIR and data in the
form of a sequence of directory entries
• Each entry is a struct dirent
57. Directory layer
• A directory is a file with an inode type T_DIR and data in the
form of a sequence of directory entries
• Each entry is a struct dirent
struct dirent {
ushort inum; // free, if zero
char name[DIRSIZ];
};
#define DIRSIZ 14
59. dirlookup
• Searches a directory for an entry with the given name
• Signature: struct inode* dirlookup(struct inode
*dp, char *name, uint *poff)
60. dirlookup
• Searches a directory for an entry with the given name
• Signature: struct inode* dirlookup(struct inode
*dp, char *name, uint *poff)
• If it finds it, it returns a pointer to the corresponding inode via
iget, unlocked, and returns the offset of the entry within the
directory
61. dirlink
• Writes a new directory entry with the given name and inode
number into dp
62. dirlink
• Writes a new directory entry with the given name and inode
number into dp
• Signature: int dirlink(struct inode *dp, char
*name, uint inum)
63. Path names
• Path name look up is enabled by multiple calls – one for each
path component – to dirlookup
64. Path names
• Path name look up is enabled by multiple calls – one for each
path component – to dirlookup
• namei takes a path and returns the corresponding inode
65. Path names
• Path name look up is enabled by multiple calls – one for each
path component – to dirlookup
• namei takes a path and returns the corresponding inode
• nameiparent is similar but returns the inode of the parent
directory
66. Path names
• Path name look up is enabled by multiple calls – one for each
path component – to dirlookup
• namei takes a path and returns the corresponding inode
• nameiparent is similar but returns the inode of the parent
directory
• Both make a call to namex internally
68. namex
• Starts by deciding where the path evaluation begins
• If the path begins with /, evaluation starts at the root
69. namex
• Starts by deciding where the path evaluation begins
• If the path begins with /, evaluation starts at the root
• Otherwise, the current directory
70. namex
• Starts by deciding where the path evaluation begins
• If the path begins with /, evaluation starts at the root
• Otherwise, the current directory
• Uses skipelem to parse the path into path elements
71. namex
• Starts by deciding where the path evaluation begins
• If the path begins with /, evaluation starts at the root
• Otherwise, the current directory
• Uses skipelem to parse the path into path elements
• For each iteration (depending on the number of path elements),
looks up name within the current path element inode till it finds
the required inode and returns it
72. File descriptor layer
• Everything in Unix is a file and this interface is enabled by the file
descriptor layer
73. File descriptor layer
• Everything in Unix is a file and this interface is enabled by the file
descriptor layer
• Each process has its own open files (or file descriptor) table
74. File descriptor layer
• Everything in Unix is a file and this interface is enabled by the file
descriptor layer
• Each process has its own open files (or file descriptor) table
• Each open file is represented by struct file
76. file
• struct file is simply a wrapper around an inode or a pipe;
plus an I/O offset
77. file
• struct file is simply a wrapper around an inode or a pipe;
plus an I/O offset
• Each call to open creates a new struct file
78. file
• struct file is simply a wrapper around an inode or a pipe;
plus an I/O offset
• Each call to open creates a new struct file
• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset
79. file
• struct file is simply a wrapper around an inode or a pipe;
plus an I/O offset
• Each call to open creates a new struct file
• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset
• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes
80. file
• struct file is simply a wrapper around an inode or a pipe;
plus an I/O offset
• Each call to open creates a new struct file
• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset
• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes
• When would this happen?
81. file
• struct file is simply a wrapper around an inode or a pipe;
plus an I/O offset
• Each call to open creates a new struct file
• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset
• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes
• When would this happen?
• a happens when a process opens a file and then dups it and b
takes place when it makes a call to fork
82. file
• struct file is simply a wrapper around an inode or a pipe;
plus an I/O offset
• Each call to open creates a new struct file
• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset
• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes
• When would this happen?
• a happens when a process opens a file and then dups it and b
takes place when it makes a call to fork
• Reference count tracks the number of references to a particular
open file
83. file
• struct file is simply a wrapper around an inode or a pipe;
plus an I/O offset
• Each call to open creates a new struct file
• If multiple processes open the same independently, they will have
their own struct file for it with a local I/O offset
• The same struct file can appear multiple times within a) A
process’s file table, and b) Across multiple processes
• When would this happen?
• a happens when a process opens a file and then dups it and b
takes place when it makes a call to fork
• Reference count tracks the number of references to a particular
open file
• Read/write access is tracked by readable/writable fields
84. Global file table
• All open files in the system are kept within a global file table
(ftable)
85. Global file table
• All open files in the system are kept within a global file table
(ftable)
• ftable has corresponding functions to:
1 Allocate a file: filealloc
86. Global file table
• All open files in the system are kept within a global file table
(ftable)
• ftable has corresponding functions to:
1 Allocate a file: filealloc
2 Create a duplicate reference: filedup
87. Global file table
• All open files in the system are kept within a global file table
(ftable)
• ftable has corresponding functions to:
1 Allocate a file: filealloc
2 Create a duplicate reference: filedup
3 Release a reference: fileclose
88. Global file table
• All open files in the system are kept within a global file table
(ftable)
• ftable has corresponding functions to:
1 Allocate a file: filealloc
2 Create a duplicate reference: filedup
3 Release a reference: fileclose
4 Read from a file: fileread
89. Global file table
• All open files in the system are kept within a global file table
(ftable)
• ftable has corresponding functions to:
1 Allocate a file: filealloc
2 Create a duplicate reference: filedup
3 Release a reference: fileclose
4 Read from a file: fileread
5 Write to a file: filewrite
91. File manipulation
• filealloc: Scans the file table for an unreferenced file
(f->ref == 0) and returns a new reference
• filedup: Increments the reference count
92. File manipulation
• filealloc: Scans the file table for an unreferenced file
(f->ref == 0) and returns a new reference
• filedup: Increments the reference count
• fileclose: Decrements the reference count
93. File manipulation
• filealloc: Scans the file table for an unreferenced file
(f->ref == 0) and returns a new reference
• filedup: Increments the reference count
• fileclose: Decrements the reference count
• If f->ref == 0, underlying pipe or inode is released
94. File manipulation (2)
• filestat: Invokes stati and ensures that the file represents
an inode
95. File manipulation (2)
• filestat: Invokes stati and ensures that the file represents
an inode
• fileread and filewrite:
1
Check whether the operation is allowed by the open mode
96. File manipulation (2)
• filestat: Invokes stati and ensures that the file represents
an inode
• fileread and filewrite:
1
2
Check whether the operation is allowed by the open mode
Patch the call through to either the underlying pipe or inode
implementation
97. File manipulation (2)
• filestat: Invokes stati and ensures that the file represents
an inode
• fileread and filewrite:
Check whether the operation is allowed by the open mode
Patch the call through to either the underlying pipe or inode
implementation
3 If the wrapper is around an inode, the I/O offset would be used
and then advanced
1
2
98. File manipulation (2)
• filestat: Invokes stati and ensures that the file represents
an inode
• fileread and filewrite:
Check whether the operation is allowed by the open mode
Patch the call through to either the underlying pipe or inode
implementation
3 If the wrapper is around an inode, the I/O offset would be used
and then advanced
4 Pipes have no concept of offset
1
2
99. System calls
• sys_link and sys_unlink edit directories by creating or
removing references to inodes
100. System calls
• sys_link and sys_unlink edit directories by creating or
removing references to inodes
• sys_link creates a new name for an existing inode
101. System calls
• sys_link and sys_unlink edit directories by creating or
removing references to inodes
• sys_link creates a new name for an existing inode
1 Takes as arguments two strings old and new
102. System calls
• sys_link and sys_unlink edit directories by creating or
removing references to inodes
• sys_link creates a new name for an existing inode
1 Takes as arguments two strings old and new
2 Increments its nlink field – Number of links
103. System calls
• sys_link and sys_unlink edit directories by creating or
removing references to inodes
• sys_link creates a new name for an existing inode
1 Takes as arguments two strings old and new
2 Increments its nlink field – Number of links
3
Creates a new directory entry pointing at old’s inode
104. System calls
• sys_link and sys_unlink edit directories by creating or
removing references to inodes
• sys_link creates a new name for an existing inode
1 Takes as arguments two strings old and new
2 Increments its nlink field – Number of links
3
4
Creates a new directory entry pointing at old’s inode
The new directory entry is on the same inode as the existing one
106. create
• Creates a new name for a new inode
• Generalizes the creation of three file creation system calls:
107. create
• Creates a new name for a new inode
• Generalizes the creation of three file creation system calls:
1 open with the O_CREATE flag creates a new file
108. create
• Creates a new name for a new inode
• Generalizes the creation of three file creation system calls:
1 open with the O_CREATE flag creates a new file
2 mkdir creates a new directory
109. create
• Creates a new name for a new inode
• Generalizes the creation of three file creation system calls:
1 open with the O_CREATE flag creates a new file
2 mkdir creates a new directory
3 mkdev creates a new device file
110. create (2)
• Makes a call to dirlookup to check whether the name already
exists
111. create (2)
• Makes a call to dirlookup to check whether the name already
exists
• If it does not exist, creates a new inode via a call to ialloc
112. create (2)
• Makes a call to dirlookup to check whether the name already
exists
• If it does not exist, creates a new inode via a call to ialloc
• If create has been invoked by mkdir (T_DIR), it initializes it
with . and .. entries
113. create (2)
• Makes a call to dirlookup to check whether the name already
exists
• If it does not exist, creates a new inode via a call to ialloc
• If create has been invoked by mkdir (T_DIR), it initializes it
with . and .. entries
• Finally, it links it into the parent directory
115. Buffer cache eviction policy
• xv6’s buffer cache uses simple LRU eviction
• A number of different policies can be implemented such as FIFO,
not frequently used, aging, random, etc.
116. Buffer cache eviction policy
• xv6’s buffer cache uses simple LRU eviction
• A number of different policies can be implemented such as FIFO,
not frequently used, aging, random, etc.
• The buffer cache is currently a linked list but an efficient
implementation can replace it with a hash table and/or a heap
117. Buffer cache eviction policy
• xv6’s buffer cache uses simple LRU eviction
• A number of different policies can be implemented such as FIFO,
not frequently used, aging, random, etc.
• The buffer cache is currently a linked list but an efficient
implementation can replace it with a hash table and/or a heap
• The buffer cache can also be integrated with the virtual memory
system to enabled memory-mapped files (mmap in Linux)
118. Today’s task
• xv6 has no support for memory-mapped files
• Come up with a design to implement mmap1
1
http://man7.org/linux/man-pages/man2/mmap.2.html
119. Reading(s)
• Chapter 6, “File system”, from “Code: directory layer" onwards
from “xv6: a simple, Unix-like teaching operating system”