To free up some space, you may need to manually remove some of the older directories.
If you drill down through the directory tree, you’ll see that there are, indeed, a great many files. All kernel headers, including those left over from previous kernel versions installed on your machine. So just what goes on in /usr/src? Well it turns out that that’s where the kernel headers are kept. This time the guilty finger pointed straight to /usr/src:
So I moved down to /usr and ran find once again: The problem obviously lay somewhere within the /usr directory. So you’ll have to delete one or two unneeded files just to get yourself going.Īt any rate, with that out of the way, find from my root directory returned this: Find saves its raw data in a temporary file…but it can’t do that as long as you have no free inodes. xdev -type f | cut -d "/" -f 2 | sort | uniq -c | sort -nīut there’s a catch. But what could possibly be generating enough files to drain my inode supply? Tracking down the directories containing the most files (i.e., using up the most inodes) can be done using some variation of this find command run from your root directory: Suitably informed (and embarrassed) I remembered that df -i will display file system inode usage, and here’s what it looked like for me: I’ll admit that I didn’t immediately think to look at the inodes – as I said above: who knew…? But a quick Google search revealed that I wasn’t the first guy to get hit with this. Touch: cannot touch ‘/home/ubuntu/newfile’: No space left on device Just to be sure, I tried to create a new file in my home directory (to rule out some kind of permissions problem). No space? I ran df and saw that there were still plenty of free GBs on hand. Note the “No space left on device” warning.
Unable to create `/usr/src/linux-headers-3.13.0-100/drivers/staging/dgap/Kconfig.dpkg-new' (while processing `./usr/src/linux-headers-3.13.0-100/drivers/staging/dgap/Kconfig'): No space left on device
ASCIIDOCFX DOWNLOAD UPDATE
No trouble there.īut when I logged into my server to run a security update the other day, I was hit with this:ĭpkg: error processing archive /var/cache/apt/archives/linux-headers-3.13.0-100_3.13.0-100.147_all.deb (-unpack): In the case of my home workstation, I’ve got more than 60 million inodes in total, of which only 2% are being used. To see your limit, run df -i and check out the value for your root directory under the Inodes columnįilesystem Inodes IUsed IFree IUse% Mounted on
ASCIIDOCFX DOWNLOAD DOWNLOAD
Just like the available disk space determines the upper limit on the files you can create or download to a computer, the number of files you can have is similarly capped by the an inode limit. You can see the inode numbers for each of the objects within a directory by running ls -i There will usually be exactly one inode for each file or directory (the exception being hard linked files that can share a single inode). Until, that is, ignoring the status of my inodes actually brought down my server.įirst though, just what is an inode? It’s an object used by Unix systems to identify the disk location and attributes of files within a filesystem. Who knew that ignoring the status of your inodes could bring down your Linux server? I can’t say the possibility crossed my mind all that often.