NATIONAL UNIVERSITY OF SCIENCES AND TECHNOLOGY

SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCES

OPERATING SYSTEM (CS-330)

END SEMESTER PROJECT REPORT

SUBMITTED TO: SIR TAUFIQUE UR REHMAN

SUBMITTED BY:

NAME CMS ID DISTRIBUTION

MUHAMMAD HASSAN IRFAN 464849 UBUNTU

MUHAMMAD AHMAD RAZA 466747 DEBIAN

ABDUL AZIZ ZAFAR 469987 REDHAT

SYED MUNEEB UR REHMAN 465315 ANDROID

BUKHARI

CLASS + SECTION: BESE-14 -A

 Table of Contents

File System and System Monitoring Tools in Android ....................................................... 4

Section A: Understanding & Analysis ............................................................................... 4
Section B: Cross Platform Design, Application & Implementation Strategies ..................... 4
Section C: Security & Risk Mitigation .............................................................................. 5
Section D: Module Evolution, Feature Integration & Bug Analysis .................................... 5
File System and Monitoring Tools in Red Hat Linux ......................................................... 6
File System & System Monitoring Tools In Ubuntu ........................................................... 9
Section A: Understanding & Analysis ............................................................................... 9
System Monitoring in Ubuntu: .................................................................................... 10
Section B: Cross-Platform Design, Application & Implementation Strategies ................... 10
Section C: Security & Risk Mitigation ............................................................................ 11
Section D: Module Evolution, Feature Integration & Bug Analysis .................................. 11
Section E: Recommendation and Ranking of Distributions for PAK OS Development ...... 12
File System and Monitoring Tools in Debian ................................................................... 13
File System and Monitoring in Linux Distributions ...................................................... 13
Cross-Module Interactions:......................................................................................... 14
Stakeholder Requirements: ......................................................................................... 14
Cross-Platform Design, Application & Implementation................................................ 15
Design and API Differences ..................................................................................... 15
File System Behavior across Device Categories......................................................... 15
Performance, Security, Compatibility, and Usability Comparison ............................. 15
Security & Risk Mitigation ............................................................................................. 17
Vulnerabilities and Attack Surfaces ............................................................................ 17
Embedded Security Mechanisms ................................................................................. 17
Fallback and Recovery Strategies ................................................................................ 18
Evolution, Feature Integration & Bug Analysis ............................................................... 18
Debian’s File System Evolution and Comparison ......................................................... 18
Most-Requested Features (Forums and Trackers)........................................................ 19
Proposed Next-Generation File System for Debian....................................................... 19
 Historical Bugs and Analysis ....................................................................................... 20
Recommendations for PAK OS....................................................................................... 20
References ..................................................................................................................... 21
 File System and System Monitoring Tools in Android

Section A: Understanding & Analysis

1. Scope and Presentation Modifications

This report focuses on analyzing the File System and System Monitoring Tools of the
Android operating system in comparison with Ubuntu, Debian, and Red Hat. It covers
architecture, security, platform differences, and potential improvements.

2. Key Responsibilities of the Module

The Android File System is responsible for secure data storage, file access control, and
compatibility with app sandboxing. Monitoring tools provide real-time performance,
debugging, and diagnostic data, which are essential for developers and system stability.

3. Cross-Module Interactions

The File System closely interacts with memory management, I/O operations, and user-
level access APIs like the Storage Access Framework. Monitoring tools access logs,
memory usage, and process states to provide relevant data.

4. Stakeholder Requirements

Developers require detailed debugging and tracing tools like Perfetto and logcat.

Admins prioritize secure storage and audit trails.

End-users need efficient, secure file access with minimal performance overhead.

Section B: Cross Platform Design, Application & Implementation

Strategies
1. Behavioral Differences Across Distributions

The Android File System differs from Ubuntu (ext4), Red Hat (XFS), and Debian (ext4)
due to its focus on mobile devices using F2FS and EROFS optimized for flash storage.
Monitoring tools in Android (logcat, dumpsys, Perfetto) are tightly integrated with the
application layer, while Linux distributions use generalpurpose tools like journalctl and
systemd.

2. Implementation on Different Device Categories

On mobile devices, Android’s File System ensures optimal read/write speeds, power
efficiency, and secure access. Desktop/server systems in Ubuntu/Red Hat use journaling
file systems and volume managers like LVM for scalability.

3. Comparison Table

See Section 4 in the original document. Key comparisons include encryption methods
(fscrypt vs LUKS), monitoring tools (logcat vs systemd), and volume management
strategies. Android focuses on mobile centric optimizations, unlike general purpose
Linux distros.

Section C: Security & Risk Mitigation

1. Attack Surfaces & Vulnerabilities

Risks include buffer overflows in logging tools, unauthorized access to shared/external

storage, privilege escalation through flawed Scoped Storage APIs.

2. Embedded Security Mechanisms

Android employs sandboxing, SEAndroid (SELinux for Android), file based encryption,
and app permissions to mitigate threats.

3. Recovery Strategies

Fallback mechanisms include recovery mode for corrupted partitions, watchdog timers to
restart system services, and secure boot to validate system integrity.

Section D: Module Evolution, Feature Integration & Bug Analysis

1. Historical Evolution

Android evolved from YAFFS2 to ext4, then to F2FS/EROFS. Ubuntu and Red Hat
moved from ext3 to ext4/XFS. Monitoring tools grew from dmesg to Perfetto with trace
visualizations.

2. Commonly Requested Features

Enhanced sandboxing
More transparent permissions
Better developer access to logs
Storage performance improvements
Privacy focused monitoring tools

3. Next Version Suggestions

User Improvements: better storage transparency, UI for log access, permission manager.
Performance: compressed file systems, smarter cache layers.
UX: better file access UI, autolog archiving, crash recovery prompts.
Developer Upgrades: API hooks in logging tools, safer file API wrappers.

4. Historical Bugs

Example: Scoped Storage bypasses (CVE20200069), logcat overflow (DoS vectors).

Fixed via SEAndroid policies, capped buffers. Tools: static analyzers, fuzzers, SELinux
audit tools.

File System and Monitoring Tools in Red Hat Linux

1. Introduction

For this project, we focus on the File System and Monitoring Tools within the Red Hat
Linux distribution. The File System is fundamental to the operating system, providing the
structure for storing, organizing, and accessing data. Monitoring tools are crucial for
observing system performance, identifying bottlenecks, and ensuring stability.
Understanding their implementation and capabilities is essential for comprehending
overall OS functionality. This report will explain the significance of these modules,
compare their complexity and uniqueness across Ubuntu, Android, and Debian, and
highlight Red Hat's strengths and weaknesses in these areas.

2. Research Questions / Scope

Our research aims to explore the following questions:

• How are the core file system functionalities implemented differently in Red Hat
compared to Ubuntu, Android, and Debian?
• What are the primary monitoring tools available in Red Hat, and how do they
compare in features and usability to those in the other distributions?
• How does the Red Hat file system interact with other core components like
memory management and process management?
• What are the unique security features and considerations related to the file system
and monitoring tools in Red Hat?
3. Breakdown of Study Areas

• File System (Internal Responsibilities and Architecture): The file system in

Red Hat, typically utilizing ext4 as the default, manages disk space, inodes,
permissions, and the overall directory structure. It interacts closely with the
 kernel's virtual file system (VFS) layer, providing a consistent interface for
applications regardless of the underlying storage device.
• Monitoring Tools (Internal Responsibilities and Architecture): Red Hat
provides a suite of command-line tools (e.g., top, htop, vmstat, iostat, sar) and
graphical tools (e.g., Cockpit) for real-time and historical performance monitoring
of CPU, memory, disk I/O, and network activity. These tools gather data from
kernel statistics and system files.
• Comparison Across Distributions:
o Ubuntu: Often emphasizes user-friendliness and includes more visually
oriented monitoring tools by default. While the underlying file system
(typically also ext4) is similar, the default configuration and available
utilities might differ slightly.
o Android: Employs a different file system primarily based on a Flash-
friendly File System (F2FS) or ext4, optimized for mobile devices and
flash storage. Monitoring tools are often more geared towards battery and
resource management for mobile applications.
o Debian: Known for its stability and choice, Debian offers a wide range of
file system options and monitoring tools, similar in depth to Red Hat but
potentially with different default selections and community-driven
support.
• Security Risks and Failure Points: Potential risks in Red Hat's file system
include permission vulnerabilities, data corruption due to hardware failure, and
security breaches through mounted file systems. Monitoring tools themselves
could be targets for malicious actors or misconfigured to provide misleading
information.
• Historical Development: Red Hat has a long history of contributing to and
adopting advancements in file system technology (like the transition to ext4 and
XFS support) and integrating robust monitoring capabilities aligned with
enterprise needs.
4. Planned Comparison Table

Feature Red Hat Ubuntu Android Debian

Architectural VFS layer, VFS layer, VFS layer, VFS layer,
Design/APIs POSIX file POSIX file Android- POSIX file
system APIs system APIs specific file system APIs
system APIs
 Core ext4, xfs, lvm2, ext4, xfs, F2FS, e2fsprogs ext4, xfs,
Tools/Libraries mount, umount lvm2, (for ext4), btrfs, zfs-fuse,
(FS) mount, mount, vold mount
umount
Core top, htop, vmstat, top, htop, top, dumpsys, top, htop,
Tools/Libraries iostat, sar, vmstat, logcat, Android vmstat, iostat,
(Monitoring) systemctl status, iostat, sar, Studio Profiler sar, systemctl
Cockpit systemctl status, various
status, desktop
GNOME monitoring
System tools
Monitor
Major Emphasis on User- Optimized for Strong
Differences stability, friendly, mobile, community
enterprise broader different default focus, wide
features, strong hardware file system, range of
SELinux support out- focus on app- choices,
integration. of-the-box, specific emphasis on
more GUI- monitoring. free software.
centric
default tools.
Usability Geared towards More user- Designed for Flexible, can
system friendly for developers and be tailored to
administrators. general debugging. different user
desktop use. levels.
Performance Robust and well- Generally Performance- Can be
(General) tuned for server good for optimized for optimized for
workloads. desktop use. mobile devices. various
workloads.

5. Red Hat: Strengths and Weaknesses

Strengths:

• Stability and Reliability: Red Hat is renowned for its rigorous testing and focus
on stability, making its file system and monitoring tools highly dependable for
critical enterprise environments.
• Security Focus: Strong integration with SELinux (Security-Enhanced Linux)
provides enhanced security for the file system and system processes, offering
 granular control over access and preventing unauthorized modifications.
Monitoring tools often have features to audit security-related events.
• Enterprise-Grade Tools: Red Hat provides powerful and comprehensive
command-line monitoring tools like sar for historical data analysis and Cockpit
for a web-based graphical interface suitable for server management.
• Extensive Documentation and Support: Red Hat offers excellent official
documentation and professional support, crucial for understanding and
troubleshooting complex file system and monitoring configurations.
Weaknesses:

• Steeper Learning Curve: The emphasis on command-line tools and the

intricacies of SELinux can present a steeper learning curve for users unfamiliar
with Linux system administration compared to more user-friendly distributions.
• Potentially Less User-Friendly Default GUI Monitoring: While Cockpit is
available, the default desktop environment might offer less visually intuitive
monitoring tools compared to Ubuntu's GNOME System Monitor out-of-the-box.
• Licensing Costs: Red Hat Enterprise Linux (RHEL) requires a subscription,
which can be a barrier for individual users or smaller organizations compared to
the free nature of Ubuntu, Android, and Debian.

File System & System Monitoring Tools In Ubuntu

Ubuntu is a user-friendly Linux OS based on Debian widely used on desktops and
servers. It uses the ext4 file system by default which supports journaling for data safety.
Securitys is handled by AppArmor, which limits what programs can do. Tools like top
and htop monitor CPU and memorys using data from /proc

Section A: Understanding & Analysis

Linux file systems control where data is stored on disk. They employ data structures
known as inodes to index every file. When a file is deleted, the inode of the file simply
gets "unlinked" from its name, and the data becomes difficult to retrieve. Another
important concept is journaling: most contemporarys Linux file systems (ext3, ext4 etc.)
initially record changes to a journal before actually making them. Journaling protects the
disk in case the system crashes by enabling the file system to redo incomplete operations
during boot. Simply put, journaling is when the file system writes new data to a logs
initially and commits it later to the primary storage in a way that maintains consistency.
Recovery is made significantly faster and partials data corruption is avoided.
Ubuntu ext4 file system is the default since Ubuntu 9.10. Ext4 (the fourth "extended"
file system) is a journaling file system that superseded ext3 and ext2. Ext4 added
journaling checksums, delayed allocation, and extents which means clustering
contiguous blocks to enhance performance. Extents allow ext4 to allocate larger
contiguous areas to files, which accelerates writes.

System Monitoring in Ubuntu:

Linux system monitoring tools help users and administrators understand how the system
is performing by showing real time data about CPU usage, memory consumption, disk
activitys and running processes. On Ubuntu, tools like `top` and `htop` gather this
information by reading from special virtual directories such as `/proc` and `/sys`, which
the Linux kernel uses to expose live system data. The `top` command shows CPU and
memory stats for each process, while `htop` provide a more user friendly view where
users can scroll throughs processes , it sort them, and even stop or restart them directly.

Section B: Cross-Platform Design, Application & Implementation

Strategies

When designing file systems or monitoring tools to work on multiple platforms

(Ubuntu, Red Hat, Debian, Android), one key idea is the Linux Virtual File System
(VFS) layer. The VFS provides a common API for file operations (open, read, write etc),
no matter whats the underlyings file system is. This means a program written for Ubuntu
(ext4) can usually run unchangeds on Debian or Red Hat they all use Linux and similar
VFS interfaces like, if you write a utility in C or Python it will work on Ubuntu, Debian,
and Red Hat because alls follow POSIX conventions. VFS even lets multiple file systems
coexists

Cross-platform strategies:

• Use standard APIs and tools: it code against POSIX C functions or common
libraries. Like a C program using open() and read() works on any Linux
includings. Scripting languages like Python or shell scripts (bash) are also
portable across Ubuntu, Debian, and Red Hat. Android does have a limited shell.
• Abstract differences: For any low levels differences use configuration files or
environments checks. For example if a tool needs to examine disk usage, it can
read /proc/mounts rather than assume /etc/mtab.
• Consider hardware: Android devices usually use ARM CPUs and have custom
partition layouts. In contrast, Ubuntu has often x86_64. Cross compilation or
containerization like using qemu or Docker images can help test on different
architectures.
 • Use the VFS for portability: Because of the VFS file system features can be
swappeds. For example Ubuntu uses ext4 by default, but it also supports XFS via
kernel modules. You can design tools assuming ext4 but ideally use generic file
APIs so the code also works if the system uses XFS.

Another cross platform consideration is how monitoring data is presented. For Linux
Ubuntu,Debian,Red Hat you can design a tool that reads /proc and writes output to a
terminal. That same tool could run on Android’s shell. Howevers i searched, Android
devices often require root to access all /proc data, and they expect graphical app. If
PAK OS includes mobile devices, we can use Android’s developer APIs like the
MemoryInfo or ActivityManager for an app based monitor

Section C: Security & Risk Mitigation

File systems and monitoring also involve security considerations. Journaling is partly
about integrity, it prevents data corruption which is a form of risk mitigation.

security features come in other forms too:

• File permissions and ownership: Unix style permissions are the first defense.
Every file and directory on all Linux systems has permission bits that restrict
access. Android also uses similar permissions, plus each app runs as a separate
user ID. This means that by default one user or app cannot read another’s private
files unless explicitly alloweds
• Mandatory Access Control (MAC): Ubuntu uses AppArmor by default to
control what apps can access, using profiles that limit file and system access. Red
Hat and Android use SELinux instead which labels files and processes and
enforces strict rules even root can be limited.
• Disk encryption: To protect data at rest, Linux distributions support full-disk or
file-based encryption. Ubuntu and Debian installers can set up LUKS encryption
for whole disks or partition
• Monitoring and alerting: System monitoring helps with security by spotting
strange behavior, like unknown processes or CPU spikes. Tools like top, auditd,
or sysstat can show issues early. On Android, logcat or SafetyNet are use

Using file system checks (like fsck) and backups is crucial. If a file system ever gets
marked as “unclean”, the system will automatically run fsck on reboot to repair it.
Journaling means fsck is usually quick because most of the recovery is done by replaying
the journal

Section D: Module Evolution, Feature Integration & Bug Analysis

File systems and monitoring tools have evolved significantly. In the Linux world:
 • File systems: Linux started with ext2 (no journaling), then moved to ext3 (with
journaling), and later to ext4, which improved speed and reliability with features
like extents and checksums. Ubuntu mostly use ext4
• Monitoring tools: in ubuntu,the earliest tools like top, and iostat came from the
procps and sysstat packages. Over time, newers tools appeared: htop added
interactivity, glances and bpytop (now btop) added more GUI like displays, and
container focused tools appeared for modern workloads. Kernel level tracing is a
recents areas tools like bcc/bpftrace can profile system calls and I/O in detail.

The journaling in ext4 and XFS fixed many corruption bugs present in non-journaled
systems. Monitoring tools also had to adapt: the old /proc/stat format changed slightly
between kernel versions, and tools had to adjust parsing. But generally, the evolution
has been incremental: new file system capabilities (like resizing partitions online, or
encryption support) get added as features without completely overhauling the system.

When analyzing bugs, its often filesystem drivers or tools that need updates. For
example, if a new SSD has unusual behavior, the ext4 or F2FS driver might need a patch
to align I/O properly. Or a new kernel could expose a race condition in /proc reading. Part
of Module Evolution is that distributions backs port critical fixes: Ubuntu’s LTS kernels
and Red Hat’s RHEL backport many updates to keep file systems and monitoring tools
secure and stables

The file system and monitorings “modules” have evolved from simple to more complex:
from ext2 to journaling ext4/XFS, from top to interactive dashboards. Each new feature
was integrated after testing. Bug analysis is ongoing: communities track issues on places
like [Link]. But by 2025, ext4 and XFS are very mature, F2FS is stable for Android
use, and monitoring tools are rich and battle tested.

Section E: Recommendation and Ranking of Distributions for PAK OS

Development
For the hypothetical PAK OS Development, choosing a base Linux distribution involves
weighing stability, ease of use, and available support. We focus on Ubuntu, Red Hat (or
RHEL derivatives), Debian, and mention Android as a special case.

Ubuntu offers a balanced combination of user-friendliness, stability, and extensive

community support, making it ideal for both newcomers and experienced users. Its
widespread adoption in educational and business environments, especially in South Asia,
ensures robust local support.

• File System: Ubuntu utilizes the ext4 file system by default, known for its
reliability and performance.
• Security: AppArmor is enabled by default in Ubuntu, providing mandatory
access control through easy-to-manage profiles
 • System Monitoring: Ubuntu comes with essentials monitoring tools like top, and
users can install htop and sysstat for enhanced system performance tracking .
• Package Management: The APT package manager, along with support for PPAs
and Snap packages, offers flexibility in software installation and updates.

File System and Monitoring Tools in Debian

Understanding & Analysis

Scope and Responsibilities of the File System Module:

The file system module in an operating system kernel manages the logic for on-disk file
systems, handling files, directories, metadata and system calls such as open, read, write,
and delete. In Linux, the Virtual File System (VFS) layer provides a uniform API to
userland, while individual file system drivers interpret specific on-disk formats. The
module interfaces with the VFS for file operations, utilizes the buffer/page cache to store
data in RAM, and communicates with block device drivers for I/O operations. It also
ensures metadata updates and journaling for crash consistency. Key tasks include
directory lookups, file creation/deletion, space allocation, permission checks, and error
recovery. The file system collaborates with memory management (via the page cache)
and the I/O subsystem (through block I/O scheduling) to optimize performance and data
integrity.

File System and Monitoring in Linux Distributions

Debian and Ubuntu, which is derived from Debian, rely on the Linux kernel’s file
systems, typically defaulting to ext4, a journaling successor to ext3, for root and data
partitions. Ext4 offers journaling for crash recovery, extents for efficient large-file
handling, and delayed allocation for optimized write ordering. Both distributions support
XFS, Btrfs, and other Linux file systems, though ext4 remains prevalent. Red Hat
Enterprise Linux (RHEL) historically used ext3/ext4 but now defaults to XFS, a 64-bit
journaling file system, in modern releases. Android, a Linux-based OS, primarily uses
ext4 for internal partitions, with increasing adoption of F2FS (Flash-Friendly File
System) for flash storage. Older Android devices used YAFFS2 for raw NAND, but since
Android 2.3, ext4 is common on eMMC, and newer devices, like Pixel phones, leverage
F2FS for enhanced flash performance.

Monitoring tools differ across platforms. Debian and Ubuntu provide standard Linux
utilities such as df and du for disk usage, inotify, auditd, and dnotify for file event
monitoring, and iostat/vmstat for I/O statistics, alongside system logs. RHEL offers
similar tools, often installed via yum install sysstat, with enhanced logging through auditd
and SELinux alerts. Android, lacking a traditional shell, uses logcat, dumpsys, 1 and its
SELinux/Audit framework for file-access tracking. All these systems depend on the
kernel’s VFS and audit subsystems for monitoring.

Cross-Module Interactions:
The file system module is closely integrated with memory management and I/O sub
systems. Linux utilizes available RAM as a dynamic page cache for file data, where free
memory is consumed by cached disk pages and reclaimed under pressure. The VFS
maintains inode and directory entry (dentry) caches in memory to accelerate metadata
lookups. Under memory pressure, the kernel prioritizes purging the page cache, as it is
reclaimable without terminating processes. On the I/O side, the file system issues block
reads/writes through the Linux block layer, which uses I/O schedulers (e.g., CFQ,
deadline, blk-mq) to optimize request ordering. For instance, ext4’s delayed-allocation
batches writes for efficient placement by the block layer. Thus, the file system sits
between memory and I/O, leveraging caches (page, inode, dentry) to reduce disk traffic
and relying on the block I/O subsystem for physical reads/writes, with locking and
journaling ensuring consistency.

Stakeholder Requirements:
Developers: Expect a stable, POSIX-compliant file API with features like large file
support, asynchronous I/O, symlinks, ACLs, and extended attributes. They value reliable
behavior across versions and robust debugging tools. Debian’s stability and free software
ecosystem, with its extensive libraries and predictable file system semantics, make it
appealing.

System Administrators: Require robust, manageable storage with stability,

recoverability (journaling, reliable fsck), and comprehensive tools (fsck, tune2fs,
xfs_repair, lvdisplay, quotas). They prioritize security, performance tuning (mount
options, I/O scheduling), and enterprise features (LVM snapshots, RAID). RHEL caters
to administrators with certified packages and strict SELinux enforcement, while
Debian/Ubuntu rely on community documentation.

End Users: Demand simplicity and data safety, expecting file systems that are fast,
reliable, and recover transparently from crashes. Features like mount-on-insert for USB
drives, desktop disk utilities, and automatic resizing are valued, alongside data integrity
and performance for everyday tasks. Intuitive monitoring tools, graphical or command-
line, and minimal downtime on errors are essential.
Cross-Platform Design, Application & Implementation
Design and API Differences
Debian and Ubuntu share a Linux-based design, using dpkg/apt for package management,
adopting stable kernel releases, and targeting general-purpose use (desktops, servers,
embedded). Ubuntu enhances desktop usability with GNOME and Snap packaging,
incorporating newer kernels, while Debian prioritizes long-tested versions for stability.
Both adhere to POSIX/Linux-standard APIs. RHEL uses RPM/Yum/DNF packaging,
emphasizes certified enterprise software, and lags in adopting bleeding-edge kernels for
stability, enforcing SELinux by default for commercial users. Android employs a
modified Linux kernel with Google’s Bionic libc, exposing a Java-based API (Storage
Access Framework, content providers) rather than POSIX calls. Hardware support aligns
with these goals: Debian/Ubuntu support diverse architectures (x86_64, ARM, RISC-V),
RHEL focuses on enterprise hardware (x86_64, ARM, IBM Power), and Android
optimizes for flash based mobile hardware (eMMC, UFS).

From a UI perspective, Ubuntu provides desktop utilities like Disk Usage Analyzer and
Disk Utility. RHEL’s GUI tools (GNOME Disks, Cockpit) target administrators. Debian
emphasizes flexibility with command-line tools and manual partitioning. Android
abstracts file system details, automatically mounting partitions and providing user-facing
file managers for specific storage locations.

File System Behavior across Device Categories

On desktops/laptops (HDD/SSD), ext4 and XFS offer strong throughput and latency for
mixed workloads, with journaling ensuring quick crash recovery. SSDs benefit from
ext4’s TRIM support. On servers, XFS (RHEL’s default) excels in multi-threaded I/O
and large file systems (up to 18 exabytes), optimized for databases/VMs. On
embedded/mobile devices (eMMC/flash), wear-leveling is critical; Android’s ext4/F2FS
usage leverages flash-aware allocation, with F2FS offering faster random writes on
NAND. Journaling on mobile devices is typically metadata-only to reduce write
amplification. For removable media (USB drives), FAT32/exFAT or NTFS ensure
interoperability, though Linux handles these with limited metadata support.

Performance, Security, Compatibility, and Usability Comparison

OS/Distributi Performance Security Compatibility Usability
on

Debian(Linux) Uses ext4 by Standard Unix Broad hard ware Very stable,
default (fast permissions, support (x86, minimal in
for small optional ARM, etc.). staller/UI.
files, efficient SELinux/AppArm Supports most Command-
 journaling). or, LUKS Linux file line tools
Lacks special encryption, ACLs. systems (ext4, dominate.
acceleration Ext4 journaling XFS, Btrfs, JFS, Less novice
for large files ensures crash ReiserFS, friendly
beyond resilience. Fewer FAT/NTFS) out- (manual
extents. default restrictions of-the-box. partitioning,
Stable but than RHEL. no default
not tuned for snap shots).
extreme Strong
throughput. community
support.

Ubuntu(Linux) Similar to AppArmor by Similar to Highly user

Debian (ext4 default, full-disk Debian, with friendly
default). encryption on strong support (graphical
Newer install, regular for newer installer,
kernels/stora security up dates. hardware via auto-mount,
ge drivers, Strong community mainline kernels. desktop
optional for Snaps/security utilities).
ZFS/Btrfs. alerts. Snap and
GPU/SSD graphical
optimizations updates
in some LTS enhance
releases. desktop
experience.

Red Defaults to SELinux enforcing Supports Geared for

Hat(RHEL) XFS by default, strict enterprise sysadmins.
(excellent for policies, certified hardware Auto
large files, up dates, ACLs, (RAID, SAN, provisionin
parallel I/O), encryption, secure IBM).XFS/ext4 g installer
tuned for boot. Emphasizes for Linux disks. (LVM,
enterprise compliance. More NTFS requires RAID),
(NUMA, locked down. extra packages; GUI tools
multi-disk). ISO9660 (Cockpit).
LVM+XFS supported. Less Back ported
scales to exotic FS than drivers for
petabytes. Debian stability.
Older RHEL Commercia
usedext4. l support.
 Android(Linux Optimized SELinux enforcing Supports ARM, Designed
) for flash (Android 5.0+), somex86. Uses for non-
(ext4/F2FS). app sandboxing YAFFS/F2FS/ex technical
Partition- with unique UIDs, t4 internally; users:
level dm-crypt/FBE reads abstracted
journaling for encryption, Google FAT/NTFS on file
quick boot. Play Protect. SD. Closed managemen
Performance drivers limit t, in visible
varies by compatibility. mounts,
kernel/vendor app-based
. Limited file access,
multi user touch UI,
caching. over-the-air
updates.

Security & Risk Mitigation

Vulnerabilities and Attack Surfaces
File system code is susceptible to bugs exploitable by attackers. For instance, CVE-2025
23150 revealed a use-after-free in ext4’s directory handling, risking crashes or memory
corruption. CVE-2022-49879 involved malformed ext4 directory entries causing kernel
panics when mounting crafted images, enabling denial-of-service attacks. These highlight
risks from corrupted on-disk structures or malicious disk images. Attack surfaces include
user-controllable elements like file names, symlinks, device nodes, or inode numbers.
Privileged binaries (e.g., e2fsck, mkfs, fsck) interacting with the file system are potential
targets, as are remote file systems (NFS, SMB) vulnerable to network attacks. Monitoring
tools like inotify can be overwhelmed, missing file changes, and malicious partition
tables or EFI boot entries can hijack mounts. Complex features like journaling, extended
attributes, LVM, or multipath may harbor bugs compromising integrity or leaking data.

Embedded Security Mechanisms

Modern Linux systems, including Debian, employ layered protections:

Mandatory Access Control: Debian supports AppArmor or SELinux to confine

processes. Android enforces SELinux to isolate apps/services, denying unauthorized
actions. RHEL ships with strict SELinux policies, minimizing compromise impact.
Encryption: Linux’s dm-crypt (LUKS) provides transparent block-device encryption
with strong algorithms. Distributions support full file system encryption at boot via
passphrase prompts, protecting data at rest.

Integrity Flags: Files on ext2/3/4 can be marked immutable (chattr +i), preventing
modifications even by root. AppArmor/SELinux can enforce read-only or no-execute
policies.

Mount Options: Security flags like noexec, nosuid, and nodev on untrusted volumes
block code execution or device creation.

Integrity Checking: Tools like AIDE or Tripwire verify filesystem contents

cryptographically, while fsck and journaling detect corruption at boot.

Isolation: Linux containers and Android’s multi-user model use namespaces and
SELinux domains to limit exploit scope.

Fallback and Recovery Strategies

File system failures from disk errors, corruption, or bugs are mitigated by redundancy
and recovery tools. Journaling enables metadata repair after improper shutdowns. Tools
like e2fsck or xfs_repair fix inconsistencies on boot. Administrators should maintain
backups or snapshots (LVM, Btrfs) for data restoration. RAID or multi-path disks
provide hardware resilience. Debian allows mounting corrupted file systems read-only
(e.g., via Live CD) for repairs. Root-on-ZFS/Btrfs with snapshotting enables rollback to
known good states. For monitoring, kernel logs alert admins to inotify queue overflows.
Combining backups, journaling, and monitoring (SMART, smartmontools) forms a
robust safety net.

Evolution, Feature Integration & Bug Analysis

Debian’s File System Evolution and Comparison
Debian’s file system evolution mirrors Linux advancements. Early releases used ext2 (no
journaling), but by 2002 (Woody), ext3 added journaling. Ext3 remained default until
Debian 8 (Jessie, 2018) adopted ext4, introducing extents, delayed allocation, journal
checksums, and larger volume support. RHEL followed a similar path, using ext3/ext4 in
versions 5/6 and XFS in 7+ for large-scale performance. Android transitioned from
YAFFS2 to ext4 in Gingerbread (2.3) and now uses F2FS on newer flash devices for
better performance.
Most-Requested Features (Forums and Trackers)
Users frequently request features absent in ext4, such as snapshots, transparent
compression/encryption, and easier online resizing. Debian forums highlight demands for
Btrfs-like COW snapshots, check summing, and compression. Administrators seek SSD
optimizations (like F2FS), auto-repair with less downtime, enhanced GUI tools, and per
filesystem AppArmor/SELinux profiles. Developers request improved asynchronous I/O
and monitoring.

Proposed Next-Generation File System for Debian

A future Debian file system could include:

• User-Driven Improvements:

Built-in snapshots without LVM/ZFS (Btrfs-inspired).

Transparent compression with minimal CPU overhead.

Native per-directory/file encryption, simplifying LUKS.

Online shrink/resize for mounted file systems.

Improved NTFS/exFAT support for Windows interoperability.

• Performance Optimizations:

Multi-threaded journaling for multi-core CPUs.

Smarter write coalescing for SSDs.

On-the-fly defragmentation (like XFS, Btrfs).

Direct I/O for database workloads.

Tuned defaults.

• User Experience Enhancements:

GUI utilities for fsck/resize with progress indicators.

Automatic repair suggestions for detected corruption.

Snapshot rollback on boot for user-friendly recovery.

Simplified auto-mount management for external drives.

Filesystem-level copy/move progress feedback.

• Developer/API Upgrades:

Stable in-kernel APIs for backward compatibility.

Standardized extended attributes for metadata (e.g., tags, quotas).

Richer inotify-like interface for recursive directory watching.

Historical Bugs and Analysis

Debian’s file system stack has faced notable bugs. Ext4 addressed ext3 limitations but
introduced issues like CVE-2022-49879 (invalid directory entries causing kernel panics)
and CVE-2025-23150 (use-after-free in directory handling). Patches added validation
(e.g., checking directory record lengths) and were back ported via Debian’s security
tracker. Impacts included denial-of-service or data corruption. Detection relied on code
audits, fuzzing (e.g., Syzkaller for CVE-2025-23150), and user-reported fsck failures.
Ext4’s journal checksums and faster fsck (up to 6x over ext3) improved robustness. Other
bugs involved large file/inode handling, online resize issues, and data ordering under
heavy loads, tracked via Debian’s bug tracker and test suites (LTP).

Recommendations for PAK OS

Based on this analysis, the top two distributions for building PAK OS are:

1. Debian GNU/Linux- Open-source, Stable, Versatile

Strengths: Debian’s stability, vast hardware support, and 50,000+ package repository
make it highly versatile. Its mature file system tools and strong security track support
customization. Its open-source nature avoids licensing costs, ideal for a national or
educational OS.

Weaknesses: Conservative updates may delay support for newer hardware or file
systems. It lacks commercial support contracts, and default security policies are less strict
than RHEL’s.

Suitability: Debian’s openness and architecture support suit a locally developed OS for
diverse devices. Its stability and community-driven model align with national initiatives,
supporting critical systems like servers and educational platforms.

2. Red Hat Enterprise Linux

Strengths: RHEL offers certified stability, long-term support, and XFS for large-scale
systems. SELinux enforcement ensures robust security, ideal for government or
institutional use. Commercial support and tools like Cockpit enhance manageability.
Weaknesses: RHEL requires subscriptions, though provide free alternatives. Its rigid
release cycle may include older software, offset by back ported fixes. It may be
heavyweight for lightweight projects.

Suitability: RHEL suits PAK OS needs for security and reliability in critical
deployments. Free clones address cost concerns, offering enterprise-grade features
without licensing fees.

Justification: Debian and RHEL balance openness and enterprise support. Debian’s
customizability and ecosystem suit a homegrown OS, while RHEL’s security and support
meet strict requirements. Ubuntu could be a runner-up for desktop usability, but Debian
underpins it. Android is unsuitable for desktop/server use, and other distributions
(Fedora, SUSE) offer shorter support or smaller ecosystems.

References
1. File Systems, [Link] html
2. Linux Performance Tuning: Dealing with Memory and Disk IO, Yugabyte, https:
//[Link]/blog/linux-performance-tuning-memory-disk-io
3. Ext4- Debian Wiki, [Link]
4. Chapter 1. Overview of available file systems, Red Hat Enterprise Linux 9, https:
//[Link]/en/documentation/red_hat_enterprise_linux/9/html/managing_
file_systems/overview-of-available-filesystems_managing-file-systems.
5. What is Android’s file system?, Stack Overflow, [Link]
questions/2421826/what-is-androids-file-system
6. F2FS- Wikipedia, [Link]
7. File system drivers (Part 1), Linux Kernel Documentation, [Link]
labs. [Link]/refs/pull/189/merge/labs/filesystems_part1.html
8. Which OS is better? Red Hat (RHEL) vs. Debian, IONOS, [Link]
com/digitalguide/server/know-how/red-hat-vs-debian
9. Security-Enhanced Linux in Android, Android Open Source Project, https://
[Link]/docs/security/features/selinux
10. CVE-2025-23150 Impact, Exploitability, and Mitigation Steps, Wiz, [Link]
[Link]/vulnerability-database/cve/cve-2025-23150
11. dm-crypt- Wikipedia, [Link]
12. ‘chattr’ Commands to Make Important Files IMMUTABLE in Linux, Tecmint, 7
[Link]
13. Ext3- Debian Wiki, [Link]
14. Android moving from YAFFS2 to ext4, Forensic Focus Forums, [Link]
[Link]/forums/general/android-moving-from-yaffs2-to-ext4

15. Ubuntu Wiki: Linux Filesystems Explained

 [Link]
16. Debian Wiki: Ext4
[Link]
17. Ubuntu Version History (Wikipedia)
[Link]
18. [Link]: Samsung's F2FS Filesystem
[Link]
19. Android AOSP Docs: Android Kernel File System Support
[Link]
20. Red Hat Blog: How to Tune the Linux Kernel with the /proc Filesystem
[Link]
21. Ubuntu Server Docs: AppArmor
[Link]
22. Red Hat SELinux Guide
[Link]
single/using_selinux/index
23. Android Security Docs: Android Security Overview
[Link]
24. Red Hat: File System Family Ext4
[Link]
us/red_hat_enterprise_linux/8/html/managing_file_systems/overview-of-available-file-
systems_managing-file-systems