4

Instead of configuring my Nextcloud (Linux/Nginx/PGsql/PHP) server to look for a folder on my spinning hard drive mounted at /mnt/HDDfs/, I Sym-Linked /var/Nextcloud_Data so it points to /mnt/HDDfs/Nextcloud_Data and then pointed my Nextcloud config to /var/Nextcloud_Data. This way, if I ever decide to change the name of my mountpoint, I don't have to touch the DB, as I can simply edit the Symbolic Link.

At first it seemed like a great idea, but then I remembered that my root / drive is an SSD, which can only withstand limited wear compared to a traditional magnetic platter; even if wear by usage is marginal on nowadays' disks, hammering specific cells of a drive over and over isn't exactly the best idea.

What I'm asking is: when a program loads and/or writes to a location with a symlink in it, does the OS load the symlink every single time from the source location and then follow it to the real target and perform actions there or does it "cache" symlinks and translate /var/Nextcloud_Data/filename to /mnt/HDDfs/Nextcloud_Data/filename directly?

Additional info:

  • Operating system: Ubuntu Server 18.04 LTS with all latest patches and upgrades.
  • Disk Drives: a WD RED Hard Disk connected via SATA and a PCIe M.2 (Samsung 960 EVO) SSD.
  • File Systems: both the drives are GPT formatted with Ext4 file systems.
  • Motherboard: Asus Z170-Deluxe (a desktop board)
  • 1
    you may want to look into smartctl and WEAR_LEVELING_COUNT if you are worried it is getting hit hard unnecessarily – ron Oct 12 '18 at 20:58
  • @ron thanks for the suggestion! I just installed smartmontools and it seems a very useful program. – Manchineel Oct 13 '18 at 12:28
11

It's fine, for many reasons.

First, the concern with flash drives is the number of writes, not the number of reads.

Second, this concern applies to older or cheaper drives with poor firmware or poor drivers, but not to modern drives on modern operating systems. Modern SSD have good enough wear leveling and modern OSes have drivers that distinguish overwrite from erase (TRIM) so it takes a very long time before the number of writes starts to become a concern. At this age, magnetic drives are often dead from mechanical-related reasons such as humidity or dust in the wrong place or mechanical damage.

Reading through a symbolic link may update its access time depending on the system configuration. Linux defaults to updating a file's access time only once a day. So even if there was a concern over the number of writes to the drive, one write would be one day, not one access through the symbolic link.

The kernel keeps information about the symbolic link in its disk cache like any other information it reads from the disk. It doesn't keep a cache that says “/var/Nextcloud_Data/filename redirects to /mnt/HDDfs/Nextcloud_Data/filename”, but it maintains a cache that says “/var/Nextcloud_Data is a symbolic link whose target is /mnt/HDDfs/Nextcloud_Data”. This means that as long as the cache entry is still present, it won't read from the drive. This has no bearing on how often the access time is updated: that's a function of when the file is accessed, not of when the information about the file is transferred from the drive.

  • Also, even on writes of the same file over and over "specific cells" of the drive aren't getting hammered (the OPs stated concern): The drive firmware maps "disk sectors" to its internal storage and changes that map with every write so that cells wear evenly. (And does lots of other things too, of course, like move sectors around to different cells, etc. etc..) – davidbak Oct 12 '18 at 22:54

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.