I prefer to keep my OS and applications on one partition and /home/ on another.

I intend to replace the current / drive with an SSD, then symlink /home/myuser/.local/ to a directory on the SSD because some applications are installed there. This is because I find the SSD far more performant. Might having to traverse through a symlink on the classic HD (non-SSD) hinder the performance of the applications stored in ~/.local? I could imagine this being the case because the HD will need to stop whatever it's doing and move the head over to wherever ~/.local is stored to access it.

2 Answers 2


Might having to traverse through a symlink on the classic HD (non-SSD) hinder the performance of the applications stored in ~/.local?

Absolutely not. Resolving a symlink on a spinning rust under the worst case scenario will take less than a second, from then on it will be cached and subsequent accesses will be nearly instant.

(This is a friendly reminder about the importance of regular backups - SSD disks tend to die abruptly and unexpectedly and often without a possibility to get any data back).

  • 1
    Thank you. In fact one of the reasons that I prefer classic old HDs for /home/ is that they are safer for data (in my opinion). Another is obviously cost.
    – dotancohen
    Commented Feb 8, 2023 at 14:45
  • 1
    SSDs also regularly do Trim which means data recovery of older data is impossible. HDD do not remove old data until overwritten, so data may be recoverable. So backups with SSD are even more important.
    – oldfred
    Commented Feb 8, 2023 at 15:11

If you are interested in the individual performance of disk accesses, you can use the BCC (BPF Compiler Collection) set of tools to get timing data from the kernel. The tools are probably available in your distribution in a package called bcc-tools or similar.

Of interest here is the biosnoop tool, which lists each read or write operation on a disk, and how long it took. On my system I need to do:

sudo /usr/share/bcc/tools/biosnoop

It takes a few seconds to start, writing out a header. The snoop trace output for a command like sum /etc/systemd/bootchart.conf, a file I don't usually read, might be:

99.305   sum    1134   sda     R  33889239  4096       3.02

This shows the sum command did a R read at the given sector of 4096 bytes, which is the block size for this filesystem. It got a reply in 3.02 milliseconds. If I repeat the sum command many times, the snoop trace does not show the read operation happening again, as it is cached by the kernel. The same is true for looking up directory entries, and following symbolic links.

  • Thank you. The caching seems to be the key.
    – dotancohen
    Commented Feb 8, 2023 at 14:44

You must log in to answer this question.

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