Am I hammering my SSD by keeping a symlink on it?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
2
down vote

favorite












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)









share|improve this question





















  • you may want to look into smartctl and WEAR_LEVELING_COUNT if you are worried it is getting hit hard unnecessarily
    – ron
    1 hour ago














up vote
2
down vote

favorite












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)









share|improve this question





















  • you may want to look into smartctl and WEAR_LEVELING_COUNT if you are worried it is getting hit hard unnecessarily
    – ron
    1 hour ago












up vote
2
down vote

favorite









up vote
2
down vote

favorite











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)









share|improve this question













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)






filesystems hard-disk symlink ext4 nextcloud






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked 4 hours ago









alex2003super

1184




1184











  • you may want to look into smartctl and WEAR_LEVELING_COUNT if you are worried it is getting hit hard unnecessarily
    – ron
    1 hour ago
















  • you may want to look into smartctl and WEAR_LEVELING_COUNT if you are worried it is getting hit hard unnecessarily
    – ron
    1 hour ago















you may want to look into smartctl and WEAR_LEVELING_COUNT if you are worried it is getting hit hard unnecessarily
– ron
1 hour ago




you may want to look into smartctl and WEAR_LEVELING_COUNT if you are worried it is getting hit hard unnecessarily
– ron
1 hour ago










1 Answer
1






active

oldest

votes

















up vote
5
down vote



accepted










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.






share|improve this answer






















  • Thanks a lot! Much appreciated!
    – alex2003super
    3 hours ago










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f475145%2fam-i-hammering-my-ssd-by-keeping-a-symlink-on-it%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
5
down vote



accepted










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.






share|improve this answer






















  • Thanks a lot! Much appreciated!
    – alex2003super
    3 hours ago














up vote
5
down vote



accepted










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.






share|improve this answer






















  • Thanks a lot! Much appreciated!
    – alex2003super
    3 hours ago












up vote
5
down vote



accepted







up vote
5
down vote



accepted






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.






share|improve this answer














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.







share|improve this answer














share|improve this answer



share|improve this answer








edited 3 hours ago









Stephen Kitt

150k23332400




150k23332400










answered 3 hours ago









Gilles

514k12110201549




514k12110201549











  • Thanks a lot! Much appreciated!
    – alex2003super
    3 hours ago
















  • Thanks a lot! Much appreciated!
    – alex2003super
    3 hours ago















Thanks a lot! Much appreciated!
– alex2003super
3 hours ago




Thanks a lot! Much appreciated!
– alex2003super
3 hours ago

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f475145%2fam-i-hammering-my-ssd-by-keeping-a-symlink-on-it%23new-answer', 'question_page');

);

Post as a guest













































































Comments

Popular posts from this blog

What does second last employer means? [closed]

Installing NextGIS Connect into QGIS 3?

One-line joke