Member Avatar for DJSAN10

Okay, so I don't know much about this and maybe that is why the doubt. I am pretty sure there must be some precaution if some one tries to create (can say a virus) like this :

while(1)
{
   /* creat system call. to create files continuously. Not difficult to give different file name each time */
}

Inode list doesn't get exhausted here right? But what is done to avoid this ? Or does it mean that we cannot create anymore files?

  • 2 Contributors
  • 2 Replies
  • 183 Views
  • 7 Hours Discussion Span
  • Latest Post Latest Post by DJSAN10

Dani AI

Generated

As suspected, a tight loop that keeps creating files can exhaust filesystem metadata (inodes) and stop further file creation. Which resource actually runs out depends on the filesystem: ext-family filesystems normally allocate a fixed pool of inodes at format time (so you can run out of inodes even with free blocks), while filesystems such as XFS/btrfs allocate inodes dynamically and behave differently. (manpages.debian.org)

When the inode table is exhausted the kernel returns ENOSPC (“No space left on device”) on create/open calls — not a friendly “memory low” popup. To confirm an inode shortage, check inode usage and look for deleted-but-still-open files (these still hold inodes until the process closes them). Useful quick checks: 

df -i
lsof +L1
find /path -xdev -type f | wc -l

If df -i shows 100% IUse, new file creation will fail. (access.redhat.com)

Systems don’t magically protect against a user or process that creates millions of files; protection is an admin task. Enable per-user or per-project inode quotas (soft/hard limits on number of files), isolate untrusted workloads in containers or cgroups and apply memory/IO caps, and place large-volume temporary data on filesystems intended for many small files. If an ext filesystem was created with too few inodes, the usual remedies are moving data or recreating the filesystem with an adjusted inode ratio. (debian.org)

Practical recovery: find the offending process, stop or restart it to release any unlinked-but-open files (the inode is only freed when the last descriptor is closed), then remove excess files or adjust quotas. The unlink() semantics explain why deleted files can still consume resources until closed. (man7.org)

Summary: the risk is real; detect with df -i/lsof, mitigate with quotas/cgroups, and choose a filesystem/inode layout that matches the expected workload.

Member Avatar for sonal_salkade

You might be knowing that the system(OS) would not allow you to create those many files.It will flag you a message that says memory is low,delete some data.

Member Avatar for DJSAN10

It means that someone could mess up with any machine then. i would run my program on someone else's computer and create trouble for him. But this should not happen , right?? Does system take any care for this ?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.