Web hosting
Hosting inode limits: why file count can stop a site before storage is full
Shared-hosting inode limits cap the number of filesystem objects an account can create. Sites with millions of tiny cache/session/image derivative/mail files can exhaust inodes while using modest gigabytes, so storage planning should track file count as well as bytes.
Find the high-file-count directories
Use the control panel or shell tools where available to inspect inode/file usage by directory. Narrow from home/site to wp-content/cache, sessions, mail, logs, node_modules/vendor, thumbnails, backups, and temp paths.
Do not delete mail or application queues merely because they contain many files.
Expire generated data
Configure cache/session/temp/log retention and remove stale staging copies, old deployment artifacts, abandoned dependencies, and local backups that have an independent copy elsewhere.
For WordPress, audit image sizes generated by themes/plugins and cache plugins that leave old trees.
Change application storage pattern when needed
A workload that legitimately creates millions of small persistent objects may not fit shared hosting even if total bytes are low. A VPS or purpose-built storage/data model may provide more control.
Database and object-storage decisions should follow application access patterns, not inode count alone.
Monitor both quota dimensions
Alert on file-count/inode percentage and bytes. Track growth rate so cleanup/upgrade can happen before new mail/uploads/sessions fail. Keep the directory-level count from each review so a new cache, plugin, deployment artifact, or mailbox pattern is visible before it consumes the remaining file budget.
- Measure file count by directory.
- Apply retention to generated files.
- Move legitimate huge-file-count workloads appropriately.
- Monitor bytes plus inodes.