Operations 9 min read

Understanding Linux Inodes, File Operations, and Log Management

This article explains Linux inode table structure, how commands like ls, stat, cp, mv, and rm interact with inodes, compares hard and soft links, outlines common system log files and their formats, and demonstrates centralizing logs on a rsyslog server.

Raymond Ops
Raymond Ops
Raymond Ops
Understanding Linux Inodes, File Operations, and Log Management

Linux File System

Inode Table Structure

Each inode record stores the inode number, file type, permissions, UID, GID, link count, file size and timestamps, pointers to data blocks, and other file‑related data.

ls -i: view inode number

Image
Image

stat: view device inode number

Image
Image

#stat shows three timestamps: atime (last access), mtime (last content change, also updates ctime), and ctime (metadata change).

cp and inode

Allocate a free inode and create a new entry in the inode table.

Create a directory entry linking the name to the inode number.

Copy data to generate a new file.

rm and inode

Decrement the link count; freed inode numbers can be reused.

Place data blocks on the free list.

Delete the directory entry.

Data is not immediately removed; it is overwritten when reused.

mv and inode

If source and target are on the same device, the inode table (except timestamps) and data location remain unchanged; only directory entries are updated.

Hard links vs soft links

Hard link: shares the same inode as the source file; link count changes with creation/deletion; not supported for directories.

Soft link: has a different inode; points to a pathname; link count unchanged; can link to directories; file type differs from the source.

Log Management

System and kernel logs are managed by rsyslog according to the main configuration file

/etc/rsyslog.conf

and are typically stored under

/var/log/

.

Log entries usually contain the event timestamp, hostname, service or program name, and the event details.

Image
Image

Common log files

/var/log/messages – core system log (boot messages, I/O and network errors, user actions).

/var/log/cron – logs related to scheduled tasks.

/var/log/dmesg – kernel boot messages (also viewable with the

dmesg

command).

/var/log/maillog – mail server logs.

/var/log/lastlog – binary file recording the last login time of every user (view with

lastlog

).

/var/log/secure – authentication and authorization events (login, ssh, su, sudo, user management).

/var/log/wtmp – binary record of all logins, reboots, and shutdowns (view with

last

).

/var/log/ulmp – current logged‑in users (view with

w

,

who

, or

users

).

Linux kernel assigns numeric severity levels to log messages, from 0 (EMERG) to 7 (DEBUG).

User log commands

who – reports information about each currently logged‑in user.

w – shows users and the processes they are running.

user – simply outputs the current user.

last – displays records of successful logins.

lastb – displays records of failed login attempts.

Image
Image

Experiment: Centralize Log Files on a Log Server

Steps:

Edit

/etc/rsyslog.conf

to uncomment lines 19‑20, allowing the server to receive logs on TCP port 514.

Verify that port 514 is open.

Restart the rsyslog service.

On a client machine, configure rsyslog to send all logs via TCP to

192.168.116.8:514

.

Restart the client rsyslog service.

Generate log entries on the client and confirm that the server receives them.

Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
Image
LinuxSystem AdministrationFile SystemInodelog managementrsyslog
Raymond Ops
Written by

Raymond Ops

Linux ops automation, cloud-native, Kubernetes, SRE, DevOps, Python, Golang and related tech discussions.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.