If either one of these becomes full, new files will be unable to be created on that partition. In a classic Unix filesystem design, every filesystem, in addition to having a fixed amount of data space, has a fixed amount if inode space. I like to think of them like file headers - they tell the operating system some metadata of the file along with the location of the actual data the file contains. In this case, finding the offending job or process would require looking at Jenkins or system logs.Inodes are references to file contents within the disk. When the volume is full, the process fails with an error and the file is deleted, so then it appears that there is no issue. Again this may require drilling down to find the source of the problem.įinally, if neither of these checks turns up anything, it is possible that a Jenkins job or other process is trying to create a single file that exceeds the amount of free space. | wc -l and look for unusually large numbers. To find where this might be happening, you can go into each directory of a volume and run a simple find. Every file or directory created consumes 1 inode, and they are a finite resource.
When a volume is out of inodes but seems to have adequate free block storage, it is usually caused by the existence of a very large number of small or empty files or directories. df -i will show this as IUse% being at 100%. If a regular df does not show any volumes at 100% usage, it is possible that the volume in question is out of inodes.
Both of these may be very slow if the volume is large. Or you can use du -sh * in the directory, and drill down accordingly. For example, find /var/jenkins_home -size +100M. On the affected system (either the Jenkins controller or possibly an agent), run df and look for volumes whose Use% is 100%.įor volumes that are at or near 100% block storage used, you may want to search for "large" files, using find. The error message should indicate where the system was trying to write for example, /var/jenkins_home
0 kommentar(er)
