Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're running into an inode limit on our fileserver and I'm doing an experiment to reduce the number of inodes. How can I find out how many inodes a directory uses? I read that the linux kernel doesn't create an inode for soft-links under 60 bytes, but instead stores that symbolic link in the directory inode itself. Thus, I'm trying to shorten the length of the symbolic links to under 60 bytes and then see if this reduces the inode count.

EDIT: ( can't put newlines in comments... ) @caliban What I'm suggesting is creating 1 symbolic link to the parent directory and then having all other symbolic links point through that parent dir e.g. original links:

a -> /LONG_PATH/a
b -> /LONG_PATH/b
c -> /LONG_PATH/c

with directory symbolic link

__parent_dir -> /LONG_PATH
a -> parent_dir/a
b -> parent_dir/b
c -> parent_dir/c
share|improve this question
Unless you have many symbolic links on the filesystem, changing them is not going to make much difference in the long run. I'd bite the bullet and get some or all of the data moved to another filesystem as soon as you can book some maintenance time. – David Spillett Sep 18 '09 at 16:51
we have to have a tool that generates scads of symbolic links every time a hardware simulation is run. If we can reduce the inode usage of this one tool, it could probably increase the performance of the inode cache and reduce the number of inodes. – Ross Rogers Sep 18 '09 at 16:54
up vote 1 down vote accepted

An inode for each file and directory, that's the rule. And about the part where symbolic links less than 60 bytes are stored in the directory inode itself... I believe that's wrong too.

Essentially, when a symlink is less than 60 bytes long, it is actually stored in its own inode (that is separate from the directory inode), and a data block is not created. Thus, it speeds up reading of symlinks less than 60 bytes since a data block does not have to be read, resulting in faster operations.

share|improve this answer
shame... thanks for the explanation – Ross Rogers Sep 18 '09 at 17:01
Not a shame - it does entails performance improvements if you can keep your symlinks to less than 60-bytes, since it cuts out one (arguably slow) step of reading the data block. Do it, bring 'em all down to < 60bytes! :) – caliban Sep 18 '09 at 17:05
To your above proposition, no - in fact I think performance will regress if you do a symlink to a directory that stores the other symlinks (from what I can understand of your above comment). The best is to change LONG_PATH to as short as possible. – caliban Sep 18 '09 at 17:26
That's because the symlink to that LONG_PATH directory will be read, ALONG with the directory inode now, for each access to every individual symlink in there. – caliban Sep 18 '09 at 17:28
Oh no worries! I love chatting anyway (SU does get kind of Q&A methodical at times). Yes, it is cached in memory, but it is still ONE extra step to Symlink > Directory > Symlink. And the system always has to parse that directory symlink in case it changes. Without that symlink to that directory, it just goes Directory > Symlink. You could run some performance analysis tools - but it's my gut feeling that it will be slower. – caliban Sep 18 '09 at 18:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .