0

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
  • 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
1

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.

  • 1
    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
  • Since all the symlinks are actually in the same directory, i was going to create 1 symlink that points to that directory, and then have all the other symlinks be relative to that one directory. Do you think that would also improve things? e.g. original links ( upwards of 100 links ) a -> /LONG_PATH/a b -> /LONG_PATH/b c -> /LONG_PATH/c [...] modified links: _parent -> /LONG_PATH a -> _parent/a b -> _parent/b c -> _parent/c [...] – Ross Rogers Sep 18 '09 at 17:14
  • 1
    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
  • 1
    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
  • 1
    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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.