File Management in Operating Systems: Complete GATE Guide with Worked Examples

File management mixes names, metadata, directory paths, allocation pointers, and free-space arithmetic. Memorised definitions often fail as soon as a question changes the block size. File Management in Operating Systems: Allocation, Directories and Worked Examples follows the full name-to-block lifecycle, including system calls, permissions, and crash consistency. The report.bin calculations concentrate on block count, allocation lookup, bitmap size, and inode capacity.

What an operating system stores for a file

A file is a named logical sequence of bytes. The directory maps its visible name to a file control block, inode, or equivalent record. That record stores metadata such as size, owner, permissions, timestamps, type, link count, and data-location pointers, although the exact on-disk structure differs across file systems.

The usual operation path is create -> open -> read/write/seek -> close -> delete. After open, a process uses a file descriptor that refers to a system-wide open-file entry. That entry can retain the current offset, so repeated reads advance through the file without resolving the pathname again each time.

Let report.bin be 18 KiB with 4 KiB blocks and 4-byte pointers. Its data-block requirement is:

ceil(18 KiB / 4 KiB) = ceil(4.5) = 5 blocks

Four blocks hold 16 KiB. The fifth holds the remaining 2 KiB and has 2 KiB unused inside the allocated block.

Directory structures, path resolution, and links

A single-level directory gives every file one shared naming space. A two-level directory separates users. A tree supports nested organisation, while an acyclic shared directory also permits controlled sharing without directory cycles. In each case, the directory handles name-to-record mappings; the file record holds metadata and data pointers.

Trace /home/asha/gate/report.bin from the root. Root inode 1 contains home -> inode 2. Inode 2 contains asha -> inode 41, inode 41 contains gate -> inode 73, and inode 73 contains report.bin -> inode 110. These are four directory-name lookups. Inode 110 then supplies the 18 KiB size and five data-block locations. Cached directory entries and inodes may reduce physical I/O, but the logical resolution steps do not change.

A hard link /home/asha/latest is another directory name for inode 110, not a copied file. Creating it raises the inode's link count from 1 to 2. A symbolic link /tmp/report-link instead stores the pathname text /home/asha/gate/report.bin; it can dangle if that path is removed.

Contiguous, linked, and indexed file allocation

Apply all three methods to the same five-block file:

Contiguous allocation gives direct arithmetic and good sequential locality, but growth may require relocation and a long enough free run. Linked allocation grows easily and supports sequential access, but random access follows the chain, and one broken pointer can hide the remaining blocks. Indexed allocation centralises the addresses; if index block 12 is not cached, reaching logical block 3 needs the index-block read and then the read of block 52.

One 4 KiB index block with 4-byte pointers holds 4096 / 4 = 1024 pointers. It therefore addresses 1024 x 4 KiB = 4096 KiB = 4 MiB of file data directly through that index block.

Free-space management with a bitmap calculation

A bitmap keeps one allocation bit per disk block, making free runs easy to scan. A linked free list connects free blocks without a large bitmap. Grouping stores several free addresses together, while counting stores the start and length of each free run. For example, the run 60-67 becomes (start = 60, count = 8) instead of eight separate numbers.

Now assume a 1 TiB disk, 4 KiB blocks, one bitmap bit per block, and binary units throughout:

1. Number of blocks: 2^40 / 2^12 = 2^28.

2. Bitmap bits: 2^28 x 1 = 2^28 bits.

3. Bitmap bytes: 2^28 / 8 = 2^25 bytes.

4. Since 2^25 bytes = 32 MiB, the bitmap occupies 32 MiB.

The 2 KiB unused in the final block of report.bin is internal fragmentation. External fragmentation means enough blocks are free in total, but no sufficiently long contiguous run exists.

Inodes and multi-level indexing

A Unix-style calculation model has 4 KiB blocks, 4-byte pointers, and an inode containing 12 direct pointers plus one single-, one double-, and one triple-indirect pointer. Real file-system layouts vary. Each indirect block holds 4096 / 4 = 1024 addresses.

The addressable file data is:

• Direct: 12 x 4 KiB = 48 KiB

• Single indirect: 1024 x 4 KiB = 4 MiB

• Double indirect: 1024^2 x 4 KiB = 4 GiB

• Triple indirect: 1024^3 x 4 KiB = 4 TiB

The total is 4 TiB + 4 GiB + 4 MiB + 48 KiB = 4,402,345,721,856 bytes. Metadata blocks are excluded because this is file-data capacity.

For byte offset 50 KiB, floor(50 KiB / 4 KiB) = 12, with 2 KiB left inside that block. Direct pointers cover logical blocks 0-11, so logical block 12 is reached through entry 0 of the single-indirect block.

File-system reliability and performance

File allocation answers where a file's blocks are placed. Disk scheduling answers which pending I/O request a device serves next. File systems and disk scheduling in OS: allocation, directories and seek time works through that boundary and the seek-order calculations. File Systems and I/O for GATE: Allocation, Inodes and Worked Examples follows shared offsets and device-service-time calculations. The report.bin trace connects pathname resolution to allocation, free-space arithmetic, and inode capacity.

Buffering absorbs speed differences, caching avoids repeated device reads, and write-back improves latency but risks losing unwritten changes after a failure. Consistency checks can find structural damage, while journaling records updates to improve recovery, especially for metadata. Journaling does not automatically protect every file's contents or replace backups. RAID belongs lower in the storage stack as an availability and performance technique; it is neither a file-allocation method nor a backup.

How GATE and interviews test file management

IIT Guwahati's official GATE 2026 Computer Science syllabus lists File systems in Section 8, Operating System. The syllabus names the topic but does not assign it a fixed marks weightage.

Test the model with three prompts:

1. Map logical block 3: contiguous gives 43, linked reaches 52 after four visits, and indexed uses entry 3 to reach 52.

2. Change the bitmap block size to 8 KiB: 2^40 / 2^13 = 2^27 blocks and bits, then 2^27 / 8 = 2^24 bytes = 16 MiB.

3. Delete /home/asha/gate/report.bin: inode 110 still has /home/asha/latest, so its link count falls from 2 to 1 and its data is not freed.

KnowledgeGate's practice bank currently contains more than 150 File Management questions across directories, allocation, free space, and storage.

The short version and your next step

1. Resolve the pathname to the file record.

2. Read its metadata and current access state.

3. Map zero-based logical blocks to physical blocks.

4. Track free blocks with a bitmap, list, grouping, or counting.

5. Preserve consistency while metadata and data change.

For report.bin, that means four directory-name lookups to inode 110, five allocated data blocks for 18 KiB, and 2 KiB unused in the last block. Use the GATE Test Series for timed practice, then use the GATE CS Exam Preparation Courses & Test Series to browse the rest of the preparation path.