Mixing
Am I hammering my SSD by keeping a symlink on it?
Clash 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)
filesystems hard-disk symlink ext4 nextcloud
asked 4 hours ago
alex2003super
1184
add a comment |Â
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)
filesystems hard-disk symlink ext4 nextcloud
asked 4 hours ago
alex2003super
1184
you may want to look intosmartctland WEAR_LEVELING_COUNT if you are worried it is getting hit hard unnecessarily
– ron
1 hour ago
add a comment |Â
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)
filesystems hard-disk symlink ext4 nextcloud
asked 4 hours ago
alex2003super
1184
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
filesystems hard-disk symlink ext4 nextcloud
asked 4 hours ago
alex2003super
1184
asked 4 hours ago
alex2003super
1184
asked 4 hours ago
alex2003super
1184
asked 4 hours ago
alex2003super
1184
asked 4 hours ago
alex2003super
1184
1184
you may want to look intosmartctland WEAR_LEVELING_COUNT if you are worried it is getting hit hard unnecessarily
– ron
1 hour ago
add a comment |Â
you may want to look intosmartctland 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
add a comment |Â
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.
edited 3 hours ago
Stephen Kitt
150k23332400
answered 3 hours ago
Gilles
514k12110201549
Thanks a lot! Much appreciated!
– alex2003super
3 hours ago
add a comment |Â
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.
edited 3 hours ago
Stephen Kitt
150k23332400
answered 3 hours ago
Gilles
514k12110201549
Thanks a lot! Much appreciated!
– alex2003super
3 hours ago
add a comment |Â
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.
edited 3 hours ago
Stephen Kitt
150k23332400
answered 3 hours ago
Gilles
514k12110201549
Thanks a lot! Much appreciated!
– alex2003super
3 hours ago
add a comment |Â
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.
edited 3 hours ago
Stephen Kitt
150k23332400
answered 3 hours ago
Gilles
514k12110201549
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.
edited 3 hours ago
Stephen Kitt
150k23332400
answered 3 hours ago
Gilles
514k12110201549
edited 3 hours ago
Stephen Kitt
150k23332400
edited 3 hours ago
Stephen Kitt
150k23332400
edited 3 hours ago
Stephen Kitt
150k23332400
150k23332400
answered 3 hours ago
Gilles
514k12110201549
answered 3 hours ago
Gilles
514k12110201549
answered 3 hours ago
Gilles
514k12110201549
514k12110201549
Thanks a lot! Much appreciated!
– alex2003super
3 hours ago
add a comment |Â
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
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
you may want to look into
smartctland WEAR_LEVELING_COUNT if you are worried it is getting hit hard unnecessarily– ron
1 hour ago