This question already has an answer here:

Hard links

Given a file original.txt, a hard link hardlink.txt will point to the same inode and continue to exist even when original.txt is deleted.

Symbolic links

Given a file original.txt, a symbolic link symlink.txt will point to the file name.

Question: Which one is faster and which one is smaller?

My intuition says that hard links would be faster, as they are indistinguishable from the original file. However, everything depends on the speed of symbolic links.

Also, which one takes up less hard disk space?

I would like to see answers based on measurements, as questions like this one briefly mention size and speed, but do not detail it.

marked as duplicate by Warren Young, Anthon, slm, terdon, rahmu Nov 25 '13 at 14:07

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Faster when doing what? – Carsten S Nov 25 '13 at 12:03
  • @CarstenSchultz For writing and/or reading, but if it depends on other factors, they can be helpful in an answer too. – Ruben Verborgh Nov 25 '13 at 12:12
  • I am quite sure that after the initial opening, reading and writing take exactly the same time. – Carsten S Nov 25 '13 at 12:40
  • 1
    Unless it has to navigate a maze of symbolic links (where one symbolic link leads to another and on and on), which may take a while (and, if there's cycles, the kernel will eventually give up), I wouldn't worry about it. Symlinks are 'fast enough'. Speed shouldn't be the deciding factor in symbolic vs hard links. – Kevin Jun 8 '15 at 3:51

A symbolic-link creates a new file containing the path to the linked file. So you would create an actual new file, aproxiamtely the size of the path (relative or absolute) to the destination-file (the file the link points to).

A hard link just makes a new entry into a directory (ie. the special file that actually contains the directory's inode/names-pairs), so nothing new is created - unless the particular directory is already "full", so the inode/name-pair table must be increased (e.g. from 1024 to 2048 in kbytes) to get room for the link's entry.

I would imagine a symbolic link would take longer, since the system will need to read two files - both the link and the actual file... in addition, probably some processing of the link-file (ie. parsing the path) and possibly having to use another partition or physical disk. The hard link, would just have to read the actual file. Remember, all hard-links are "created equal", it doesn't matte which links was first (which was the "source" and which was the "destination") once they're created.


Symbolic links add a level of indirection so are slower to open than hard links although probably not enough to make a notable difference in common use cases.

The on disk size of a symlink depends of the file system implementation. I would assume it to be either of the same size with modern file system that optimize the name storage by using "fast symlinks" or slightly larger otherwise, especially when the linked pathname is too long to fit in the file data structure.

Once open, whether you use symlinks or hard links doesn't make a difference as far as read/write operations are concerned.

Edit: A symbolic link need to store the path to the linked file somewhere. Originally, this was done in a data block. Later, most file systems implemented fast symlinks where this path was stored in the file data structure itself, saving both a read and disk space.

  • Could you please elaborate on "fast symlinks"? – Ruben Verborgh Nov 25 '13 at 12:13
  • 1
    Answer updated. – jlliagre Nov 25 '13 at 12:46

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