Files, Directories and Device Management

9.1 Files and Directories — The Unix View

9.1.1 Everything Is a File and Basic Operations

In Unix and Linux everything is treated as a file. The system deals with any and every object as a file, whether it looks like plain text, a device, or a folder. That single view lets the kernel use the same set of calls for many different objects. The classic statement from the textbooks is simple: a file — a sequence of bytes with no imposed structure — is the only abstraction the kernel needs at the lowest level. Meaning comes from the program that interprets the bytes, not from the kernel.

On a file we can do a small set of core actions. We can open a file, close a file, read from a file, and write into a file. The phrasing matters: we read from a file and write into a file. Opening sets up a handle, reading and writing move bytes, closing releases the handle. Those four verbs are the base of almost all file work that follows.

Think of a file like a named box that holds bytes, and the directory like a list that tells where each box lives. The file itself holds the content; the directory holds the map. Another everyday picture is a universal power socket: many appliances look different, but they all use the same plug shape. Here the plug is the open-read-write-close pattern, and everything — disk file, tape, terminal — fits it. Where the analogy breaks: real devices have timing and error behaviour that a plain disk file does not, so programs must still handle device-specific errors even though the call looks the same.

Visual intuition: picture a long tape of bytes with a moving finger. open puts the finger at the start, read advances it and copies bytes to memory, write inserts bytes at the finger, close lifts the finger. For a device file the tape is not stored beforehand — bytes are produced or consumed on the fly — but the finger idea still holds.

9.1.2 What a Directory Holds

A directory — a folder that lists what is inside it — holds information about what is present inside that particular directory. What can be inside? Either files or other subfolders, often called subdirectories, can be present inside that directory. In implementation terms a directory is itself a file whose bytes are a table of entries, not free-form text.

File names inside a directory may be handled in two broad ways: fixed length or variable length. Fixed length means every name slot reserves the same number of bytes even if the real name is shorter. Variable length means each slot grows or shrinks with the name. Unix in particular follows the fixed length structure for directory entries, and that choice has direct limits on how long a name can be.

Real-world: This same idea of treating everything as a file is why you can list devices under /dev with the same tool you use to list normal files. Running ls /dev and ls /home goes through the same directory-read logic because both /dev and /home are directories whose entries the kernel reads as tables.

9.1.3 How This Connects to What Came Before

This session continues directly from the previous one that introduced what a file is and what a directory is. The plan here is to summarize those ideas quickly and then move forward into how the system turns a path name into the bytes on disk, and how to inspect disks and devices from the command line.

The lecture flow from here is intentional: first the static layout — how a directory entry maps name to number (section 9.2) — then the bridge from name to content via inodes (section 9.3), then the dynamic search that turns a path string into an inode (section 9.4), then the cost of that search in disk fetches (section 9.5), and finally the user-visible tools df, lsblk and fdisk that let you see the same structures from the shell (sections 9.6–9.8).

9.2 Unix Directory Entry Structure

9.2.1 The 16-Byte Entry and Its Two Parts

Unix stores directory entries in a small table with three columns visible in the teaching slide. The first column gives the byte offset in the directory — that is, where the next item sits inside the directory file itself. The source phrasing for the reconstruction is: "the difference between various row entries in that byte offset ... is 16 bytes ... every row is of size 16 bytes" and "every row ... consists of 16 bytes ... divided into two parts ... I node number ... 2 bytes ... 14 bytes ... file name."

Visual intuition: picture a ruler marked every 16 bytes. At $0$ sits entry $0$, at $16$ entry $1$, at $32$ entry $2$. Each 16-byte block is cut after 2 bytes: left slice is the number, right slice is the name. Because the cut is at the same place every time, the kernel computes the address of entry $k$ without reading names — a direct calculation.

9.2.2 The 14-Character Name Limit and What Happens on Overflow

Because $14$ bytes are fixed for the name, Unix under this layout restricts a file name to a maximum of $14$ characters. Anything longer will be truncated. The practical warning given is that if two files share the same first $14$ characters, the system may treat them as colliding and the older file might be replaced by the newer one, with a prompt in interactive use. In short, a truncated name is not a safe name.

Concretely, a name like my_very_long_filename.txt (24 chars) would be cut to my_very_long_f — only the first 14 characters kept. A second file my_very_long_fileB.txt also becomes my_very_long_f in the table, so the two entries collide.

Real-world: Modern file systems like ext4 now allow much longer variable names — typically 255 characters — but the 14-character fixed slot is the classic Unix Version 7 layout that explains the design trade-off between simple table math and name flexibility. The limit also explains old stories of name-collision bugs on legacy installations.

Visual — truncation collision: imagine two mailboxes both labelled my_very_long_f because the label cutter chops after 14 letters. From the outside they look identical, so mail for one can overwrite the other. Modern variable-length systems print the full label, so no collision.

Exam note: Expect a short theory or output-justification question on why a long file name is stored in truncated form and what the risk is when first $14$ characters match.

9.2.3 Special Entries: Dot, Dot-Dot and Root

The last column of the table shows example file names such as file1.txt, along with two special entries . and ...

• . indicates the current directory itself.
• .. indicates its parent directory.
• / indicates the root — the top of the whole hierarchy.

Those three symbols are not ordinary files; they are entries that let the system walk up or stay in place without extra bookkeeping. In the 16-byte table they look like normal rows — for example offset $0$ might be . with the inode of the current directory, offset $16$ might be .. with the parent's inode — but their meaning is fixed: . loops to the same inode, .. moves one level up, and / is the top.

A helpful memory picture: inside any folder you always find two hidden signposts — one that says “you are here” (.) and one that says “go back one level” (..). Without them the kernel would need separate logic to stay put or go up; with them the same lookup loop works for every component, including “stay” and “up.”

9.3 The Link Between Name and Content — Inodes

9.3.1 The File Name as a Link

The first two bytes in each directory entry — the I-node number — are the only connection between the name of a file and its contents. For that reason, a file name inside a directory is called a link in this context. Do not confuse this use of link with hard link or soft link in their fuller forms; here link simply means the name acts as a bridge in the directory hierarchy that points to the I-node.

Think of it like a phone book entry: the name you search is the link, and the phone number you dial is the inode number. The name lives in the directory; the contents live where the inode points. Tear out the phone book page and the phone still exists — similarly, removing a directory entry does not delete bytes until no link points to the inode and no process holds it open.

9.3.2 I-Node Number versus I-Node Structure

Care is needed with the word I-node:

• I-node number is the 2-byte integer stored in the directory entry — a short handle for a file or directory. In the classic 16-bit design it ranges $0$ to $65535$.
• I-node structure (sometimes written inode) is the larger data structure that holds ownership, timestamps, permission bits, file type, size, link count, and pointers to the various data blocks where the actual file bytes are stored.

So the directory gives you the number; the number leads you to the structure; the structure leads you to the data blocks.

A small picture was sketched: a directory such as /home/you contains an entry FOO with number 123 which goes to inode 123. That inode holds the file details and pointers, which lead to the data blocks, which finally yield the data. The chain is name $\to$ inode number $\to$ inode structure $\to$ data blocks $\to$ bytes.

Visual intuition: picture three layers. Top layer is the directory table (names + numbers). Middle layer is the wall of inode records (one per number). Bottom layer is the field of data blocks. An arrow drops from a name in the top layer to its numbered box in the middle, then fans out to blocks at the bottom. The top layer uses the 16-byte math; the middle and bottom use block math (typically $1\text{K}=1024$ bytes per block).

9.3.3 Putting It Together

A directory hierarchy is a tree-like nesting. At the top is /, inside it are subdirectories, inside those are further subdirectories and files. Each level uses the same 16-byte entry rule, and each name maps through its inode number to the next inode structure. Real-world: this is why moving a file within the same file system can be fast — the inode and blocks stay in place and only directory links move. A mv /home/a.txt /home/b.txt on the same partition just rewrites two directory rows; no byte is copied.

Worked mini-walk: /home/you/FOO with FOO → $123$. Start at /'s inode, get /'s data block, find home → get its inode, get home's data block, find you → inode, find FOO → $123$ → inode 123 → block pointers → “hello world”. Every hop repeats the same 16-byte row read and inode fetch pattern you saw in section 9.2, just nested level by level.

9.4 Path Name to Inode Translation — The namei Algorithm

9.4.1 Absolute versus Relative Paths and a Motivating Example

Initial access to a file from a user point of view is through its path name. You must know where the file lives to name it. The kernel also starts from that path name, but internally it must work with I-nodes. It converts the path plus file name into the file's I-node.

A running example carries through the whole discussion:

• cat /home/ubuntu/sp/file_name.txt where cat displays the contents of a file.
• Equivalent form cat /home/spiderman/hello.txt used when counting disk transfers.

A path can be of two types:

• An absolute path always starts from the root /, for example /home/ubuntu/sp/file_name.txt.
• A relative path is relative to the current directory and does not start from /, for example exercises/sys_pgm1/test1/mydetails.pxt when the current directory is /home/sys_pgm.

The kernel passes the path name one component at a time, where a component — the text between slashes — is the unit of lookup. Even the first / itself counts as a component that means root. The next component is the first directory name, then the next directory name, and so on, with the last component being the file name itself including its extension. The distinction that the extension is part of the name, not a separate component, was made explicit.

A path component example for /home/ubuntu/sp/file_name.txt:

• component 1: / (root)
• component 2: home
• component 3: ubuntu
• component 4: sp
• component 5: file_name.txt (name plus extension together)

Exam note: The split name + extension is one component is a common point for a short question.

9.4.2 Where the Search Starts: Root and Current Directory Inodes

All path name searches start from the current directory of the process unless the path name starts with /, which indicates start from root. The kernel therefore keeps two inode numbers handy:

• the root inode number, always available,
• the inode number of the current working directory, updated whenever a cd is issued.

An extra piece of context stored in the U area (user area) is the per-process information: what files are open for that process, what the current directory is, and what signal action to take when signals such as control-D, control-X, or control-Z arrive.

A small detail that helps intuition: inside the kernel, you think in paths, but the kernel always works with inodes. The path is the user view; the inode chain is the kernel view. The path is what you type; the inode number is what the kernel caches and locks.

9.4.3 Working Inodes and the Left-to-Right Walk

Components of the path are processed from left to right — that is the order the path is written and the order the kernel follows. A light aside noted that if a file system supported a language written right to left, the order might feel different, but on the systems in use the walk is left to right.

Every component except the last one should be either a directory or a symbolic link:

• Those intermediate inodes are called working inodes. They are the stepping stones that let the kernel reach the final file inode.
• If the working inode is a directory, the kernel looks for the current path component inside the directory entry list for that working inode. If it is not found, it returns an error. If it is found, the inode number tied to that matched name becomes the new working inode.
• If the working inode corresponds to a symbolic link, the path name up to and including the current component is replaced by the contents of the symbolic link and the pathname is reprocessed from the start, because a symlink is a shortcut that points elsewhere.

The walk is exactly the left-to-right scan of the string you typed. For /home/ubuntu/sp/file_name.txt the kernel sees the stream / → home → ubuntu → sp → file_name.txt and processes them in that string order. The Arabic aside — whether a right-to-left language would flip the order — was answered as left-to-right for almost all systems in use because the path string itself is built left-to-right.

9.4.4 The namei Algorithm Laid Out Step by Step

The algorithm that does this conversion is called the namei algorithm — spoken as "name I" — and every cat, open, or search for a file goes through this loop. “namei” literally means “name to inode.”

Pseudo-steps preserved verbatim alongside the reconstruction:

"if path name starts with the root meaning that it is absolute path ... working I node is root I node ... if not ... working I node will be the current working I node ... while there are more in the path name ... read the next component ... read the directory content ... if component matches entry ... get I node number ... release working I node ... I node of match component becomes working I node ... return working I node."

Reconstructed as structured prose with symbols:

• Let $p$ be the path string, let $\text{wd}$ be the inode number of the current working directory, let $\text{root}$ be the inode number of /, and let $W$ be the working inode.

$$W=\{\begin{array}{ll}\text{root}& \text{if }p\text{ starts with }/\\ \text{wd}& \text{otherwise}\end{array}$$

Then

$$\text{while there is a next component }c\text{ in }p:$$ $$\text{read directory content of }W$$ $$\text{if }c\text{ matches an entry in }W\text{ then }$$ $$\text{let }N=\text{inode number of matched entry}$$ $$\text{release }W$$ $$W\leftarrow N$$ $$\text{else return error}$$

When the loop ends, $W$ is the inode number of the file name itself. The algorithm returns that working inode. That inode then leads via its block pointers to the data blocks that hold the actual bytes.

The verbal audit trail above is kept intact so the step "release the working inode" is not lost — it means the old working inode's in-memory copy is no longer held as the focus moves forward. The step matters for locking: without release, the kernel would pin every directory on the path at once.

Real-world: This same loop explains why a broken intermediate directory name fails fast, while a dangling symlink causes reprocessing rather than a simple miss. Example of symlink: if sp is a symlink to /srv/data, the kernel replaces the path up to sp with /srv/data and restarts the walk from root — it does not just look for the next component inside sp.

Visual intuition: plot the path horizontally. Put a token $W$ on the start stone (root or wd). Each iteration moves the token one notch right to the next stone, after peeking inside the current stone's 16-byte table. The token never leaps; symlink is the only case that teleports the token back to the start with a new path string.

9.4.5 Student Questions During the Walk

The aside serves as a memory hook rather than a technical rule: follow the string order. The same hook helps with the exam: when asked to “show the working inode at each step,” list components left-to-right and update $W$ after each match — exactly the loop invariant above.

9.5 Disk Access Walkthrough — From cat Command to Data Blocks

9.5.1 The Example Path Used for Counting

The walkthrough example uses cat /home/spiderman/hello.txt and by analogy cat /home/ubuntu/sp/file_name.txt. The path is absolute, so the start is the root. Along the way concrete inode numbers were given: root is $2$, home is $13$, and hello.txt is $53$. Those numbers are the short handles that move while the full inode structures stay on disk until fetched.

For /home/spiderman/hello.txt the components are / → home → spiderman → hello.txt — three directories before the file, matching the four-component shape used for counting. For /home/ubuntu/sp/file_name.txt the shape is / → home → ubuntu → sp → file_name.txt — four directories before the file. The counting pattern scales with depth: each extra directory adds another inode-plus-data-block pair.

9.5.2 Step-by-Step Transfer Sequence

Each level does two fetches if not already cached: the inode structure itself and then the data block(s) that hold the directory entries. A data block — the unit the kernel moves between disk and main memory — is typically $1\text{K}$, that is $1024$ bytes.

Visual intuition: draw a ladder with two rails — left rail is inode structures, right rail is data blocks. For each level of the path you climb one rung on the left (inode) and one on the right (block). The last rung on the right finally holds the file's text. Without caching you climb both rails at every level; with caching many rungs are already warm in memory.

9.5.3 Counting Disk Operations

Real-world: on a modern ext4 host the block size may be $1\text{K}$, $2\text{K}$ or $4\text{K}$ rather than classic $1\text{K}$, and the inode number is 32-bit, but the “two per level” pattern stays identical — inode then block, lookup, next inode. Tools like stat and debugfs let you inspect the same inode numbers (stat /home shows Inode: 13 in the demo's vintage numbering) without running the full walk by hand.

9.5.4 A Second Set of Paths and an Exercise

Two shorter examples contrast absolute and relative starts:

• Absolute: /etc/passwd — starts from / as in the main example.
• Relative: current directory is /home/sys_pgm and the path given is exercises/sys_pgm1/test1/mydetails.pxt. The exercise left to the class is to walk the namei loop starting from the current directory inode rather than root and process components exercises, sys_pgm1, test1, mydetails.pxt in order, applying the same working-inode replacement at each match.

Exam note: Expect to apply the same left-to-right working-inode walk to a relative path example and to state how many inode and data block fetches occur. Label each hop as “inode $X$ → data block $X$ → lookup name → inode $Y$.”

9.6 Disk Usage Inspection — The df Family

9.6.1 What df Shows at Base

df — introduced as "disk file system" and in practice disk free — lists the file system view: file system name, total blocks, used blocks, available blocks, use percentage, and what it is mounted on. A plain df prints those columns for each mounted file system.

A typical df header reads Filesystem 1K-blocks Used Available Use% Mounted on. Each “1K-block” is the same $1\text{K}=1024$ byte unit you met in the transfer walk, so the numbers tie back: a file that needed a 1K data block contributes one to “Used,” and the free count drops by one.

9.6.2 Options That Change the View

• df -a : include all file systems, even dummy ones. In the demo the output of df and df -a looked much the same on that system, but the flag concept is that -a forces display of entries that an ordinary df may hide — pseudo and dummy file systems with zero blocks that still appear in /proc/mounts.
• df -i : switch from blocks to inode information. Instead of size, it shows total inodes, used inodes, free inodes for each file system — the handle space rather than the byte space.
• df -h : human readable sizes. The raw df prints large block counts; df -h prints sizes like 98G, 9.4G, 84G and a use percentage such as 11%. The demo highlighted /dev/sda1 with $\text{size}\approx 98\text{GB}$, $\text{used}\approx 9.4\text{GB}$, $\text{available}\approx 84\text{GB}$, mounted on / with 11% use, plus other lines at 100% use. The math is the same blocks, just scaled: $98\text{G}\approx 98\times 1024\times 1024$ K-blocks.
• df -T : add file system type column. The demo showed types such as ext4, ext3, ntfs, fat, fat32 for normal read/write, squashfs for a compressed file system that stores a whole image in squeezed form, and tmpfs for a temporary file system that keeps data in local memory for fast read/write and transfer.

Real-world: tmpfs is often used for /tmp or caches where speed matters and persistence is not needed; squashfs is common for live images. ext4 is the typical read/write default on Linux; squashfs is compressed read-only, so its “Used” is the squeezed image size, not a dynamic count.

Visual intuition: picture two gauges side by side. df -h is the fuel gauge in gigabytes — 98G tank, 9.4G used, 84G left. df -i is the ticket-roll gauge — total tickets (inodes) 6.5M, used 0.12M, free 6.43M. A file system can run out of tickets before it runs out of fuel if millions of tiny files are created — that is why -i exists.

9.6.3 Targeted and Filtered Queries

A path can be given, for example df -h / or df /home, to show only the file system that holds that mount. That answers “which device backs this directory?” without listing all mounts.

To filter by type:

• df -t ext4 : include only file systems of type ext4. On an ext4-only host this shows the real disks; squashfs and tmpfs rows disappear.
• df -x ext3 : exclude file systems of type ext3. This hides a type you are not interested in and shows everything else.
• Lowercase -t means include type, uppercase -T means show type column — the case matters. Trying df -t ext3 on a system with no ext3 prints that no file system matched, while df -x ext3 falls back to showing the rest.

Combinations like df -T -t ext4 or df -T -x ext3 are allowed; the same include/exclude logic applies while also printing the type column. So df -T -t ext4 means “show only ext4 and add the Type column,” which on the demo host highlighted the /dev/sda1 ext4 line alone.

Exam note: A question may ask to give the exact flag that yields a human-readable size view, an inode view, or a type-filtered view, or to justify output lines such as the 11% versus 100% entries. The 100% entries in the demo were the squashfs/tmpfs loop rows — they are sized exactly to their content, so used equals total by design, not because the disk is actually full.

9.6.4 Worked Command Snippets

9.7 Unix Input/Output — Character versus Block Devices

9.7.1 Memory and Device Setting

Before device talk, the memory ladder was named: main memory is RAM (random access memory), secondary memory is the hard disk, tertiary examples are tapes, and cache sits above RAM in levels L0, L1, L2 with no separate common name. That ladder matters because where bytes live decides how they move.

Visual intuition: picture a pyramid. The base is wide tapes, the middle is the disk, the top is narrow RAM, and the tip is cache. Bytes flow upward on read (disk block → RAM → cache → CPU) and downward on write. Character devices cut across this pyramid by streaming bytes without staging a whole block.

9.7.2 How to Tell the Type: ls -li on /dev

A student asked how to know whether a device is block or character oriented.

1234 crw-rw-rw- 1 root root 1, 5  ... /dev/zero   (c = character)
5678 brw-rw---- 1 root disk 8, 0 ... /dev/sda    (b = block)
9012 crw--w---- 1 root tty  4, 0 ... /dev/tty0   (c = character)

Because /dev is itself a directory, the 16-byte entry logic still applies — each device name occupies a row whose 2-byte inode number points to a special inode that, instead of block pointers, stores major/minor device numbers. So ls -li is literally reading the same directory table you studied in section 9.2, plus dereferencing the device inode.

Exam tip: if a question shows crw- vs brw- and asks “character or block?”, answer from the first letter alone: c → character, stream, no kernel block buffering; b → block, structured, kernel buffers.

9.7.3 Character Devices — Stream of Bytes, No Buffering

Character devices treat data as a stream of bytes. Examples given are main memory (RAM itself as a char device view), line printers, and terminals. The interface between the two ends is unstructured or raw, and there is no buffering provided at that interface. Whatever bytes are produced at one end should be consumed at the other with internal protocol handling to avoid overflow, but the kernel does not stage the bytes in a separate block buffer.

Think of it like a pipe with no tank: bytes flow as they come, and the sender and receiver must pace each other. If the receiver is slow, the sender must wait or bytes are lost — there is no pallet to park a whole block.

Where the analogy breaks: real terminals do have small driver queues and line disciplines, but from the programmer's view read() on a character device returns whatever bytes are available now, not a full block.

9.7.4 Block Devices — Blocks, Structure and Kernel Buffering

Block devices move data in blocks rather than single bytes. Examples are disks and tape drives. The interface is structured: a block is read or a block is written. Because a whole block is moved at once — typically $1\text{K}=1024$ bytes was quoted — the other end may not be ready to accept or process it immediately. For that reason buffering is required, and that buffering is provided by the kernel.

Think of it like pallets versus letters: character moves letters one by one, block moves a whole pallet that must be staged until a forklift is free. The pallet is the $1024$-byte block; the staging area is the kernel's buffer cache. Without the buffer, a block read would have to wait for the consumer to be instantly ready, which at block granularity is wasteful.

Visual intuition: picture the disk as a wall of 1024-byte pallets. read( block 5 ) lifts one pallet into the kernel buffer. If the process is not ready, the pallet waits on the staging floor (buffer cache) rather than being resent. Character's “letter” needs no staging floor — it is handed directly.

Exam note: A contrast question may ask for two differences and an example each, plus who provides buffering: kernel for block, no buffering for character. A safe two-point answer: (1) stream vs block, (2) kernel buffering is required for block and provided by kernel, no buffering for character — with examples line printer / terminal vs disk / tape.

9.8 Device Identification — Major and Minor Numbers, lsblk and fdisk

9.8.1 Major as Driver, Minor as Instance

Every hardware item in Linux is seen as a device, and a device works through its device driver installed in the system. The driver is the interface that makes the hardware operate.

A helpful rephrase from class: major is “what kind of device” and minor is “which one of that kind.” Opening /dev/sda with major $8$ routes to the SCSI/SATA disk driver; minor $0$ picks the whole disk, minor $1$ picks its first partition sda1, minor $5$ might pick a logical partition. The same majors appear under /dev as the MAJ:MIN pair you see in lsblk.

Visual intuition: picture a switchboard. The major number chooses the bank of operators (disk bank, loop bank, terminal bank). The minor number chooses the operator within that bank. The kernel looks up the major table once, then dispatches to the minor entry — two-level routing, not one flat number.

9.8.2 lsblk — List Block Devices

lsblk stands for list block and reports only block devices. Its columns were walked one by one:

• NAME — device name such as sda, sda1, loop0.
• MAJ:MIN — major and minor numbers, e.g., 8:0 for sda and 8:1 for sda1, 7:0 onward for loop devices.
• RM — removable flag as 0 or 1, where 0 means non-removable and 1 means removable.
• SIZE — size of the device, e.g., 100G for the main disk.
• RO — read-only flag as 0 or 1, where 1 means read-only and 0 means read and write.
• TYPE — type such as disk, part (partition), loop.
• MOUNTPOINT — where it is mounted, if at all, such as /.

Visual intuition: picture lsblk as a roster. Leftmost NAME is the human label, middle MAJ:MIN is the kernel routing pair, flags RM/RO are sticky notes (“removable?”, “read only?”), TYPE is the role, MOUNTPOINT is where it hangs in the tree. The demo's wall of loop0…loop22 with identical major 7 looks like a block of identical uniforms — same driver, many instances.

9.8.3 fdisk — Partition Tables and Details

fdisk is the partition tool known to Linux administrators for creating and editing partitions, but here it was used to inspect.

• fdisk -l lists all disks with details. Without sudo it returned permission denied, which was the cue that a privileged view is needed. With sudo fdisk -l it printed for each disk: size such as 100GB, number of sectors, total bytes, sector size 512 bytes, I/O size 512 bytes, disk label type DOS, disk identifier such as a hex mark, and for sda1 fields like boot flag yes, start sector 2048, number of sectors, size, Id, and type such as Linux or the operating system installed.

• sudo fdisk /dev/sda opens the interactive view for that disk. Options walked in the help output were:
• m help,
• a toggle bootable flag,
• d delete a partition,
• F list free unpartitioned space — which in the demo was 0 because the whole $100$ GB was already partitioned,
• L list known partition types — including FAT12, XENIX, FAT16, FAT32, AIX, NTFS, ZFS and many others,
• p print the partition table — which repeated the fdisk -l detail for sda alone,
• v verify the partition table and i print information about a partition (device, boot, sectors and so on).

The actual p run for sda echoed the earlier line: sda1 starts at 2048, occupies the bulk of the disk, shows as bootable, and carries its Id and system type. The number $2048$ appears in both fdisk -l and lsblk narratives because the first partition is aligned to 1 MB — a modern default that avoids misaligned I/O on 4K-sector drives.

Real-world: In practice most day-to-day inspection uses lsblk and df; fdisk -l is the lower-level view an administrator pulls when planning partitions. You would run lsblk to see “what is mounted where,” df -h to see “how full,” and sudo fdisk -l to see “how the disk is sliced at sector granularity” including the $512$-byte sector and $2048$ start.

Exam Guidance Summary

All exam-facing advice is gathered here, with inline markers also placed where the topics appear:

• Syllabus for the mid-semester exam is exactly the files and directories material covered up to this session, including directory entry layout, inode links, path-to-inode translation via the namei algorithm, and the df / device identification commands. No new heavy theory beyond that was added in this session. The session was the last class before the mid-semester, with no class next week.
• Question style is almost entirely commands. Expect to justify a specific output given a command, or to give the command plus option that produces a given output, with variations on flags. One or two very simple theory questions at most may appear, but the bulk is practical command use. Example patterns: “what does df -h show for /dev/sda1 at 98G/9.4G/84G 11%?”, “which flag of df shows inode counts?”, “what does ls -li /dev show for c vs b?”.
• Study source is the slides and the options listed in the slides. There is no need to learn every flag a command supports; the flags shown in class — such as df -a, df -i, df -h, df -T, df -t/-x include/exclude, ls -li /dev, lsblk, fdisk -l and fdisk /dev/sda interactive F, L, p — are sufficient, even though that list is already long. For df remember 11% vs 100% interpretation; for lsblk remember major 8 for sda/sda1 and major 7 for loop, plus RM/RO and TYPE; for fdisk remember sector size 512 bytes, start sector 2048, disk size 100GB, DOS label, and the need for sudo.
• Past paper — an old question paper with practice questions is or will be posted on the Taksila portal. That paper shows the pattern of asking for command and option and of interpreting listings such as the df table or lsblk rows. Practise by covering the output and predicting which flag produced it.
• Specific concept spotlights carried from sections:
• 14-character truncation risk (9.2): when first $14$ characters match the truncated names collide; the older file might be replaced — expect a theory justification.
• Name + extension is one component (9.4): last component of /home/ubuntu/sp/file_name.txt is file_name.txt, not txt — expect a short question on component counting.
• Working inode walk (9.4): left-to-right $W=\text{root}$ for absolute else $\text{wd}$, then 16 = 2 + 14 style lookup per component — expect to walk a relative path like exercises/sys_pgm1/test1/mydetails.pxt from /home/sys_pgm.
• Disk operation counting (9.5): each level needs inode plus $1\text{K}=1024$-byte data block; root $2$, home $13$, hello $53$ style numbers — expect to count transfers for a given path.
• df flags (9.6): -a (all including dummy), -i (inode Inodes IUsed IFree), -h (human 98G/9.4G/84G 11%), -T (type ext4/squashfs/tmpfs), -t/-x (include/exclude type) plus case trap -t vs -T.
• lsblk reading (9.8): major 8 disk vs 7 loop, minors 0/1/…/22, RM 0/1, RO 0/1, TYPE disk/part/loop, SIZE 100G; fdisk needs sudo, sector 512, start 2048.
• Presentation hints heard earlier still apply: write assumptions, show work in tables where possible, and keep handwriting and formatting clear for grading, because a table makes the 16 = 2 + 14 split and the inode walk easier to award marks for. For namei, a three-column table — step, component $c$, working inode $W$ — scores well.
• Timing — this was the last class before the mid-semester, with no class next week. Wishes for the exams were extended to all courses.

Key Industry Applications

Consolidated real-world connections for quick review:

• Real-world: Everything-is-a-file underlies the way Linux exposes devices as files under /dev, listed with ls -li (c for character, b for block, - for regular, d for directory). The same open-read-write-close path handles /etc/passwd and /dev/tty — the uniformity keeps drivers small and tools reusable.
• Real-world: The 14-byte fixed entry explains legacy systems and name-collision bugs on older Unix installations; modern ext4, xfs, ntfs and others use variable names to avoid truncation. When you see a vintage tar archive complain about truncated names, it is this $16=2+14$ limit at work; today’s 255-character limit is the variable-length successor.
• Real-world: The namei walk powers every open and cat on absolute paths such as /etc/passwd and on relative paths such as exercises/sys_pgm1/test1/mydetails.pxt. Container runtimes and web servers do millions of such walks; understanding W = \text{root vs wd} and the left-to-right stepping explains why symlink attacks must be handled by path reprocessing.
• Real-world: squashfs appears in live USB images and container layers as a compressed read-only file system; tmpfs powers /tmp and fast staging where memory speed matters. The df -T row that shows squashfs at 100% is not an alarm — it is a fixed image that is full by design, just like a container layer.
• Real-world: lsblk major 8 for disks and major 7 for loops is the standard driver numbering seen on any Linux host; RM and RO flags let scripts distinguish removable or read-only mounts. Fleet monitoring parses 8:0 vs 7:0…7:22 to separate real storage from loop-backed snaps; RO 1 marks the squashfs images that should never be written.
• Real-world: fdisk with sector size $512$ bytes and start sector $2048$ is the usual alignment seen on a DOS label 100GB disk with a single sda1 partition. The $2048\times 512=1$ MB gap is the modern alignment rule that avoids 4K-sector penalties — every cloud VM image you launch inherits it.
• Real-world: The inode-plus-$1\text{K}=1024$-byte-block counting explains cold-start latency: the first cat after boot touches root $2$ → home $13$ → file $53$ inode+block pairs; the second cat hits the buffer cache and avoids disk. Capacity planning uses df -i (inodes free) alongside df -h (blocks free) because a mail spool can exhaust inodes with tiny files while blocks look healthy.

These links stay within the lecture’s scope — each mirrors a flag, number, or walk you already traced: 16 = 2 + 14 at byte offsets $16\times k$, working inode $W$, block $1\text{K}=1024$, 98G/9.4G/84G 11% and 100% loop rows, MAJ:MIN 8:0/8:1 vs 7:0…7:22, sector $512$ and start $2048$.