DEV Community: Aditya Raj

Why is Linux Lying to you ? Inodes explained

Aditya Raj — Wed, 30 Sep 2026 12:20:39 +0000

No space left on device, but df says the disk is 1% full

I hit this on a box with 56 MB free and a filesystem that refused to create an empty file.

$ df -h /mnt/demo
Filesystem  Size  Used Avail Use%
/dev/loop0   60M   24K   56M   1%

$ touch index.js
touch: cannot touch 'index.js': No space left on device

The disk is almost empty. The error says it is full. Both are true, because they are talking about different things.

Reproduce it in thirty seconds

You don't need a broken server. Make a tiny filesystem with a tiny inode table:

dd if=/dev/zero of=/tmp/tiny.img bs=1M count=64
mkfs.ext4 -N 128 -F /tmp/tiny.img
mkdir -p /mnt/demo
mount -o loop /tmp/tiny.img /mnt/demo

for i in $(seq 1 128); do touch /mnt/demo/$i; done

touch /mnt/demo/newfile     # No space left on device
df -h /mnt/demo             # 56M free
df -i /mnt/demo             # IUse 100%

-N 128 is the whole trick. It tells mkfs.ext4 to build an inode table with room for 128 inodes and nothing more, ever.

What an inode actually is

A file on Linux is three separate things.

The inode is a record holding the metadata: permissions, owner, timestamps, size, and pointers to where the data lives. The data blocks hold the contents. And the directory entry holds the name.

That last one surprises people. The filename is not in the inode. A directory is a list that maps names to inode numbers, and that is the only place a name exists.

$ ls -li
12 -rw-r--r-- 1 eradon eradon 4232 notes.txt

That leading 12 is the inode number. The name notes.txt is just an entry in the directory pointing at inode 12.

Why moving a huge file is instant

Once names and inodes are separate, mv inside one filesystem makes sense. It doesn't move data. It removes one directory entry and creates another pointing at the same inode. A 40 GB file "moves" in a millisecond because nothing moves.

Across filesystems it's a real copy, because the inode number means nothing over there.

Why ext4 runs out

On ext4 the inode table is built when the filesystem is created, sized from a bytes-per-inode ratio, and it never grows. You can't add inodes later. There is no command for it.

Every file costs exactly one inode, regardless of size. A 4 GB video costs one. An empty file costs one. So a filesystem full of tiny files runs out of inodes long before it runs out of space — logs, cache entries, session files, mail queues, node_modules. None of them are big. All of them cost an inode.

That's the whole bug. The disk had 56 MB free and zero inodes, and touch needs an inode.

Recovering from it

Your options on ext4 are thin:

delete files you don't need, which frees inodes immediately
move a directory tree to another filesystem
create a new filesystem with a bigger inode count and mount it

resize2fs grows the filesystem, not the inode table. tune2fs -l will show you the count but won't change it.

XFS behaves differently — it allocates inodes dynamically, so it doesn't have a fixed ceiling in the same way. If you know a filesystem will hold millions of small files, that's a real argument for XFS, or for passing a much lower bytes-per-inode value at mkfs time.

Hard links: many names, one inode

If names and inodes are separate, nothing stops two names pointing at the same inode. That's a hard link.

ln notes.txt backup.txt
ls -li notes.txt backup.txt

Both show the same inode number, and the link count goes to 2. There's no original and no copy — the two names are equal, and the data exists once.

Two consequences follow:

Hard links can't cross filesystems. An inode number only means something within its own filesystem, so ln across a mount point gives you Invalid cross-device link.

A hard link needs no new inode. On our full filesystem, touch fails but this works:

ln /mnt/demo/1 /mnt/demo/another-name    # fine
ln -s /mnt/demo/1 /mnt/demo/softlink     # No space left on device

A hard link adds a name to a directory. A symlink is a new file, so it needs an inode, so it fails. That one line is the clearest demonstration of the difference I know.

What rm actually does

rm doesn't delete a file. It removes a directory entry and decrements the link count. The syscall is even called unlink.

The inode and its data survive while the link count is above zero. Only when the count hits zero and no process holds the file open does the kernel reclaim the inode and the blocks.

That second condition is the other classic "disk is full" mystery: delete a 40 GB log that nginx still has open, and du says the space is gone while df says it's still used. The space comes back when the process closes the descriptor, or you restart it. lsof +L1 lists these.

Symlinks

A symlink is a file whose contents are a path. It gets its own inode, and that inode holds text like /home/eradon/notes.txt.

Because it stores a path rather than an inode number, it can point anywhere, including another filesystem. Resolution costs an extra lookup: you hit the symlink's inode, the kernel reads the path out of it, and then resolves that path normally.

Permissions work differently between the two. Hard links all share one inode, so they share its permission bits — chmod through any name affects all of them. A symlink has its own inode and its own bits, but they're ignored: the kernel checks the target's permissions. A symlink never grants access you don't already have.

"Everything is a file", so did we break everything?

If files need inodes and inodes ran out, can the machine still fork a process or read /proc?

Yes, because there are two different things called an inode.

On-disk inodes belong to a filesystem like ext4. They live in that fixed table. They're what we exhausted.

VFS inodes are struct inode objects in kernel memory. The VFS is the layer that makes everything look like a file, and not everything behind it is on a disk. /proc and /sys are synthesised by the kernel when you look at them:

$ stat -c '%i %n' /proc/self/status
4026532042 /proc/self/status

$ df -i /proc
Filesystem  Inodes IUsed IFree IUse%
proc             0     0     0     -

It has an inode number, but procfs has no table and nothing to run out of. Exhausting ext4's inodes exhausts that filesystem, not some global pool.

A rule of thumb that gets you most of the way: if you can hold a file descriptor to it, it has an inode — sockets, pipes, epoll, timerfd, /proc entries. There are exceptions, but not many.

What to actually monitor

Most monitoring watches disk space and stops there. Add inodes:

df -i                          # inode usage per mount
du --inodes -x -d1 /var        # which directory is eating them
find /var/spool -xdev | wc -l  # count in a suspect tree

Alert on df -i the same way you alert on df -h. In production the things that generate millions of tiny files are exactly the things nobody watches: log directories without rotation, cache trees, session stores, CI workspaces.

And in containers, remember overlayfs draws on the host filesystem's inodes. One runaway container can starve the host.

The takeaway

Free space and a usable filesystem are not the same thing. When writes fail and df -h looks fine, check df -i before anything else.

The Linux process that even SIGKILL can't kill

Aditya Raj — Tue, 22 Sep 2026 05:28:04 +0000

The short version, for anyone who'd rather read it:

When a process exits, the kernel frees basically everything: address space, file descriptors, and it never schedules the task again. What stays is a small record — the PID, the exit status, and some CPU accounting — because the parent may still want to read it. That record is the zombie. SIGKILL does nothing to it because there's nothing left to kill; the kill(2) call even returns success.

It's removed when the parent calls wait(). If the parent dies first, the children are reparented to the nearest ancestor marked as a subreaper (PR_SET_CHILD_SUBREAPER), and failing that to PID 1 of that PID namespace. The walk stops at the namespace boundary, so a process in a container is never adopted by anything on the host.

The part that bites in production: in a container your application is PID 1, which makes it the reaper for everything inside. Plenty of apps never call wait() on processes they didn't spawn directly, so orphans accumulate as zombies until the pids cgroup limit is hit and nothing can fork. Fixes are tini / docker run --init, initProcessEnabled on ECS, or shareProcessNamespace on k8s so the pause container does the reaping.

Simplify PDF Generation in Node.js with html-to-pdf-pup

Aditya Raj — Sun, 05 May 2024 18:02:10 +0000

Introduction:

I have created a new npm package html-to-pdf-pup, a powerful Node.js package designed to simplify the PDF generation process. In this article, we'll explore how html-to-pdf-pup works, its features, installation process, usage scenarios, and how its optimized.

What is `html-to-pdf-pup`?

It is a Node.js package that enables developers to convert HTML and CSS content into PDF documents seamlessly. Built on top of Puppeteer, a headless Chrome browser API, html-to-pdf-pup offers a scalable, event-driven system for generating PDFs efficiently.

Features:

Highly scalable event-driven system.

Asynchronously convert multiple HTML files to PDF using multiple tabs or a single tab for queue PDF generation.

Message queue system for managing the conversion process.

Simple and easy-to-use API suitable for beginners.

Configurable options for advanced users.

Full control over the conversion process and PDF options.

Returns PDF buffer for further processing.

Dynamic height for PDFs by default.

Optimizations techniques used:

html-to-pdf-pup employs several optimization techniques to enhance performance and resource management:

Message Queue System: Utilizes a message queue system to manage the conversion process efficiently, ensuring smooth operation even with multiple conversion requests.

Single Browser Instance: Maintains only a single browser instance regardless of the number of conversion requests, reducing resource overhead.

Concurrent Tab Conversion: Opens multiple tabs for concurrent PDF conversion, maximizing throughput and minimizing processing time.

Tab Recycling: Once a tab completes PDF conversion, it immediately starts processing another request, optimizing tab utilization and reducing idle time.

Integration of Max Tab System: Integrates the maximum tab system with a single browser instance for better resource management, balancing performance and resource consumption effectively.

Why choose this package over the others:-

Light weight: html-to-pdf-pup is very light with only 17kb as unpacked size in the npm package.

Fully configurable: Unlike other packages html-to-pdf-pup is gives full control to the user with its many configurable options and also a dev mode.

Highly optimized for pdf creation: html-to-pdf-pup comes highly optimized out of the box. it has been tested to use minimal memory and resources of server. it gets these optimizations from features such as single browser instance , Tab recycling , zero resource comsumption in downtime,etc.

Scalablity: The main selling point of html-to-pdf-pup is its scalablity , here users can control how many concurrent request it can handle according to their available resources . handeling many request once can lead to faster performance but can also use more resources.

here , user can find their sweet spot according to their needs.

Open source and Documentation:html-to-pdf-pup is an open-source project with active development and maintenance. It benefits from contributions from developers worldwide, ensuring continuous improvement, updates, and enhancements. By using html-to-pdf-pup, you contribute to and benefit from the vibrant open-source ecosystem.

Installation:

To install html-to-pdf-pup, simply run the following command in your Node.js project directory:

npm i html-to-pdf-pup

Basic Usage:

Using html-to-pdf-pup is straightforward. Here's a basic example demonstrating how to convert HTML content to a PDF:

const { create_pdf } = require("html-to-pdf-pup");

let htmlData = "<html><body><h1>Hello World</h1></body></html>";

create_pdf(htmlData)
  .then((pdfBuffer) => {
    console.log(pdfBuffer);
  })
  .catch((err) => {
    console.log(err);
  });

Config Mode:

For advanced users, html-to-pdf-pup offers a config mode to customize Puppeteer , PDF configurations and also a DEV mode:

For more info refer :- npm

Conclusion:

html-to-pdf-pup simplifies the process of converting HTML and CSS content to PDF documents in Node.js. With its powerful features and optimization techniques, including scalability, asynchronous conversion, and configurable options, developers can efficiently generate PDFs for various use cases. Whether you're a beginner or an experienced developer, html-to-pdf-pup provides a seamless solution for your PDF generation needs in Node.js. Try it out in your next project and experience the convenience it offers!

Finally added the hacktober badges to github readme.md 😅️

Aditya Raj — Wed, 08 Nov 2023 11:51:16 +0000

My github

Finally added the hacktober badges to github readme.md 😅️

Aditya Raj — Wed, 08 Nov 2023 11:51:09 +0000

My github

DEV Community: Aditya Raj

Why is Linux Lying to you ? Inodes explained

No space left on device, but df says the disk is 1% full

Reproduce it in thirty seconds

What an inode actually is

Why moving a huge file is instant

Why ext4 runs out

Recovering from it

Hard links: many names, one inode

What rm actually does

Symlinks

"Everything is a file", so did we break everything?

What to actually monitor

The takeaway

The Linux process that even SIGKILL can't kill

Simplify PDF Generation in Node.js with html-to-pdf-pup

Introduction:

What is html-to-pdf-pup?

Features:

Optimizations techniques used:

Why choose this package over the others:-

Installation:

Basic Usage:

Config Mode:

Conclusion:

Finally added the hacktober badges to github readme.md 😅️

Finally added the hacktober badges to github readme.md 😅️

What is `html-to-pdf-pup`?