[opensuse] disappointing SSD experiences
Both SSD 120G: PNY SSD7CS900-120-RB bought 2018-07-21, died March 2019, replaced under warranty. Mushkin MKNSSDSR120GB bought 2018-06.21, being replaced under warranty, died Monday during 'zypper dup' from 15.0 to 15.2 on 18000 MiB partition. I really have no idea the runtime on either, as I sometimes clone whole disks (both HDD & SSD) as backup routine, and sometimes only partitions. The Mushkin was in continuous service for about 10 months ~24/7 with noatime as a mount option, and fstrim run weekly. I have 2 other 120G SSDs, a Crucial BX500 and an Adata XPG, that have been in my clone rotation on this PC. These SSDs are MBR partitioned and used only for /boot 1.2G, /usr/local/ 4G, a 16G swap not often enabled (and never enabled since I raised RAM to 32G), and 5 18G OS partitions (13.1, 15.0, 15.1, 15.2 & TW, with 15.1 in majority of use since 2019-12-26). What I'm guessing is I've gotten on average well under 10 month's service out of each before failure, considering I only bought my first SSD 29 months ago. My /home, /tmp and other user data are on rotating rust RAID1. Has anyone here had worse experience? Any suggestions to do something differently? -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/5/20 11:36 PM, Felix Miata wrote:
What I'm guessing is I've gotten on average well under 10 month's service out of each before failure, considering I only bought my first SSD 29 months ago.
My /home, /tmp and other user data are on rotating rust RAID1.
Has anyone here had worse experience? Any suggestions to do something differently?
No, (thankfully) You should get 5-10 years out of a SSD under heavy use (you would die before you exhausted the read/write life of a SSD under normal user use) I have had good luck with the samsung variants (blistering performance). If it is just 2 drives that died for you, then I'd just chock it up to bad luck. If they both died in the same box, worth checking sensors to make sure the voltages on the system are all good. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 6 Nov 2020 00:39:54 -0600 David C. Rankin wrote:
On 11/5/20 11:36 PM, Felix Miata wrote:
What I'm guessing is I've gotten on average well under 10 month's service out of each before failure, considering I only bought my first SSD 29 months ago.
My /home, /tmp and other user data are on rotating rust RAID1.
Has anyone here had worse experience? Any suggestions to do something differently?
No, (thankfully)
You should get 5-10 years out of a SSD under heavy use (you would die before you exhausted the read/write life of a SSD under normal user use) I have had good luck with the samsung variants (blistering performance). If it is just 2 drives that died for you, then I'd just chock it up to bad luck. If they both died in the same box, worth checking sensors to make sure the voltages on the system are all good.
+1 (check age & condition & output quality of power supply; check in situ operating temps) Aside: The Mushkin device has a 3.9 rating with 60 reviews, whereas the PNY device has a 4.7 rating with 6,522 reviews (G**gle). In general, I have personally had very good experiences with PNY products in the past, including one of their 120 GB SSDs. Assuming the "zypper dup" yielded a sustained / alternating maximum read / write condition and this somehow triggered the failure, this could certainly implicate power quality or temperatures. For posterity (because I know that you know better,) you're not scuffing your feet on the carpet when you're handling these devices, are you? :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carl Hartung composed on 2020-11-06 02:13 (UTC-0500):
For posterity (because I know that you know better,) you're not scuffing your feet on the carpet when you're handling these devices, are you? :)
Average humidity is high here in Fla. Detectable static electricity is rare. I have some throw rugs, but not carpet, around the PCs and work area, but mostly tile. Still, I'm usually conscious of how I handle susceptible electronics. ;) Last I checked the BIOS, voltages were all where they belong. It's a large old Antec server case with little in it. SSD is below HDDs with decent space between. I have a 12V 80mm fan blowing at their ends opposite the connections. I don't think heat is an issue, except for the fact that 2.5" SSDs are surrounded by heat insulating plastic with no apparent venting: # sensors acpitz-acpi-0 Adapter: ACPI interface temp1: +27.8°C (crit = +90.0°C) temp2: +29.8°C (crit = +90.0°C) coretemp-isa-0000 Adapter: ISA adapter Package id 0: +38.0°C (high = +79.0°C, crit = +85.0°C) Core 0: +37.0°C (high = +79.0°C, crit = +85.0°C) Core 1: +36.0°C (high = +79.0°C, crit = +85.0°C) -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Fri, 6 Nov 2020 02:47:44 -0500 Felix Miata wrote: 8< - - - - - snipped - - - - - >8
Last I checked the BIOS, voltages were all where they belong.
It could be marginal or poorly regulated and/or 'noisy' voltages where the failed SSDs were connected. I would closely inspect the cables and connectors / sockets and the associated mainboard circuitry. Likewise, I'd also check the schematics and other technical documentation to confirm precisely how much sustained power is supposed to be available at those points. Maybe some support forum posts exist for this mainboard discussing weaknesses in this area of the design? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/6/20 1:47 AM, Felix Miata wrote:
It's a large old Antec server case with little in it. SSD is below HDDs with decent space between. I have a 12V 80mm fan blowing at their ends opposite the connections. I don't think heat is an issue, except for the fact that 2.5" SSDs are surrounded by heat insulating plastic with no apparent venting:
You can't do better than an old Antex server case....
# sensors acpitz-acpi-0 Adapter: ACPI interface temp1: +27.8°C (crit = +90.0°C) temp2: +29.8°C (crit = +90.0°C)
coretemp-isa-0000 Adapter: ISA adapter Package id 0: +38.0°C (high = +79.0°C, crit = +85.0°C) Core 0: +37.0°C (high = +79.0°C, crit = +85.0°C) Core 1: +36.0°C (high = +79.0°C, crit = +85.0°C)
It's not so much the temps that are important from sensors, but the voltages, e.g. 5VSB: +5.23 V (min = +4.48 V, max = +5.52 V) Vcore: +1.38 V (min = +0.00 V, max = +2.99 V) +3.3V: +3.32 V (min = +2.97 V, max = +3.63 V) +5V: +5.10 V (min = +4.50 V, max = +5.50 V) +12V: +12.21 V (min = +10.81 V, max = +13.19 V) 3VSB: +3.29 V (min = +2.97 V, max = +3.63 V) Vbat: +2.97 V (min = +2.70 V, max = +3.30 V) You want to make sure that your voltages are well within the middle part of the range from each. Depending on your chip, you may have to scale the voltage (for example, some chipsets report 1/2 the voltage shown, etc..) It will be apparent if that is the case. man sensors3.conf under the "Compute Statement" shows how that is handled (don't forget to run sensors -s as root if you make changes) In checking then voltages, if I saw the 5V system bus voltage at 4.5 or the 12V rail voltage at 11.1, I'd worry that the power supply may be giving you problems. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin composed on 2020-11-06 17:22 (UTC-0600):
It's not so much the temps that are important from sensors, but the voltages, e.g.
As usual for man pages, there are no examples or anything else apparent in the sensors or sensors3.conf man pages explaining how to get sensors to show voltages. /etc/sensors.d/ is empty. /etc/sensors3.conf is nothing but tech babble. What about the cloning? Should I be mounting with discard instead of weekly running fstrim, or using both trimming methods? I currently using my PNY: # hdparm -I /dev/sda | grep TRIM * Data Set Management TRIM supported (limit 8 blocks) -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/6/20 5:51 PM, Felix Miata wrote:
As usual for man pages, there are no examples or anything else apparent in the sensors or sensors3.conf man pages explaining how to get sensors to show voltages. /etc/sensors.d/ is empty. /etc/sensors3.conf is nothing but tech babble.
That's from your chipset, you will either have voltages are you won't. The hardware support for sensors has been steadily dropping as chipsets cheapen. (just as with harddrive features, consumer drives/server drives) With my SSD, yast just enabled fstrim.timer on it's own. just check with # systemctl status fstrim.timer -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/6/20 5:51 PM, Felix Miata wrote:
As usual for man pages, there are no examples or anything else apparent in the sensors or sensors3.conf man pages explaining how to get sensors to show voltages. /etc/sensors.d/ is empty. /etc/sensors3.conf is nothing but tech babble. That's from your chipset, you will either have voltages are you won't. The hardware support for sensors has been steadily dropping as chipsets cheapen. (just as with harddrive features, consumer drives/server drives)
With my SSD, yast just enabled fstrim.timer on it's own. just check with
# systemctl status fstrim.timer
In data sabato 7 novembre 2020 04:39:51 CET, David C. Rankin ha scritto: thank you, learned something new. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/11/2020 06.36, Felix Miata wrote:
Both SSD 120G: PNY SSD7CS900-120-RB bought 2018-07-21, died March 2019, replaced under warranty. Mushkin MKNSSDSR120GB bought 2018-06.21, being replaced under warranty, died Monday during 'zypper dup' from 15.0 to 15.2 on 18000 MiB partition.
I really have no idea the runtime on either, as I sometimes clone whole disks (both HDD & SSD) as backup routine, and sometimes only partitions. The Mushkin was in continuous service for about 10 months ~24/7 with noatime as a mount option, and fstrim run weekly. I have 2 other 120G SSDs, a Crucial BX500 and an Adata XPG, that have been in my clone rotation on this PC. These SSDs are MBR partitioned and used only for /boot 1.2G, /usr/local/ 4G, a 16G swap not often enabled (and never enabled since I raised RAM to 32G), and 5 18G OS partitions (13.1, 15.0, 15.1, 15.2 & TW, with 15.1 in majority of use since 2019-12-26).
What I'm guessing is I've gotten on average well under 10 month's service out of each before failure, considering I only bought my first SSD 29 months ago.
My /home, /tmp and other user data are on rotating rust RAID1.
Has anyone here had worse experience? Any suggestions to do something differently?
Clone rotation. Mmm. Does this involve writing a whole partition or disk? Periodically? You should watch smartctl output on them. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Felix Miata composed on 2020-11-06 00:36 (UTC-0500): More, and puzzling, data points: # journalctl -u fstrim.service -- Logs begin at Thu 2017-09-07 21:20:47 EDT, end at Thu 2020-11-05 01:57:29 EST. -- -- No entries -- # fstrim --verbose --all /disks/boot: 518.2 MiB (543367168 bytes) trimmed on /dev/sda3 /: 8.2 GiB (8828071936 bytes) trimmed on /dev/sda8 # mount /dev/sda7 # mount /dev/sda9 # mount /dev/sda10 # mount /dev/sda11 # fstrim --verbose --all /disks/root5: 12.4 GiB (13267972096 bytes) trimmed on /dev/sda11 /disks/root4: 8.4 GiB (9040199680 bytes) trimmed on /dev/sda10 /disks/root3: 13.1 GiB (14098477056 bytes) trimmed on /dev/sda9 /disks/root1: 8 GiB (8623312896 bytes) trimmed on /dev/sda7 /disks/boot: 0 B (0 bytes) trimmed on /dev/sda3 /: 56 KiB (57344 bytes) trimmed on /dev/sda8 # systemctl status fstrim ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) Docs: man:fstrim(8) # grep 'sda8' /etc/fstab /dev/sda8 / ext4 noatime 0 1 -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata composed on 2020-11-06 00:36 (UTC-0500): More, and puzzling, data points: # journalctl -u fstrim.service -- Logs begin at Thu 2017-09-07 21:20:47 EDT, end at Thu 2020-11-05 01:57:29 EST. -- -- No entries -- # fstrim --verbose --all /disks/boot: 518.2 MiB (543367168 bytes) trimmed on /dev/sda3 /: 8.2 GiB (8828071936 bytes) trimmed on /dev/sda8 # mount /dev/sda7 # mount /dev/sda9 # mount /dev/sda10 # mount /dev/sda11 # fstrim --verbose --all /disks/root5: 12.4 GiB (13267972096 bytes) trimmed on /dev/sda11 /disks/root4: 8.4 GiB (9040199680 bytes) trimmed on /dev/sda10 /disks/root3: 13.1 GiB (14098477056 bytes) trimmed on /dev/sda9 /disks/root1: 8 GiB (8623312896 bytes) trimmed on /dev/sda7 /disks/boot: 0 B (0 bytes) trimmed on /dev/sda3 /: 56 KiB (57344 bytes) trimmed on /dev/sda8 # systemctl status fstrim ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) Docs: man:fstrim(8) # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-11-03 03:34:56 EST; 3 days ago Trigger: Mon 2020-11-09 00:00:00 EST; 2 days left Docs: man:fstrim # grep 'sda8' /etc/fstab /dev/sda8 / ext4 noatime 0 1 -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/11/2020 02.42, Felix Miata wrote:
Felix Miata composed on 2020-11-06 00:36 (UTC-0500):
More, and puzzling, data points:
# systemctl status fstrim ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) Docs: man:fstrim(8) # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-11-03 03:34:56 EST; 3 days ago Trigger: Mon 2020-11-09 00:00:00 EST; 2 days left Docs: man:fstrim # grep 'sda8' /etc/fstab /dev/sda8 / ext4 noatime 0 1
The problem is finding out when the timer did run and what was the result, if any. Perhaps try "journalctl | grep fstrim" or "grep -i fstrim /var/log/messages", which in my case both return empty. So I try "zgrep -i fstrim /var/log/messages*z" which does return things. The last entries (October) are: /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.339977+02:00 Telcontar fstrim 7949 - - /other/auxiliary: 18.2 GiB (19561299968 bytes) trimmed on /dev/nvme0n1p3 /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.340336+02:00 Telcontar fstrim 7949 - - /boot: 883.5 MiB (926412800 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.340461+02:00 Telcontar fstrim 7949 - - /: 99.5 GiB (106817015808 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724242+02:00 Telcontar fstrim 917 - - /other/auxiliary: 0 B (0 bytes) trimmed on /dev/nvme0n1p3 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724504+02:00 Telcontar fstrim 917 - - /boot: 208.3 MiB (218365952 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724647+02:00 Telcontar fstrim 917 - - /: 18.5 GiB (19850489856 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20201026.xz:<3.6> 2020-10-19T00:00:41.576785+02:00 Telcontar fstrim 5779 - - /boot: 936.5 MiB (981962752 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201026.xz:<3.6> 2020-10-19T00:00:41.577034+02:00 Telcontar fstrim 5779 - - /: 99.4 GiB (106693591040 bytes) trimmed on /dev/nvme0n1p5 So it is running. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. composed on 2020-11-07 02:55 (UTC+0100):
The problem is finding out when the timer did run and what was the result, if any.
Perhaps try "journalctl | grep fstrim" or "grep -i fstrim /var/log/messages", which in my case both return empty.
So I try "zgrep -i fstrim /var/log/messages*z" which does return things. The last entries (October) are:
# journalctl | grep -i trim Aug 03 02:08:01 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Aug 03 03:25:04 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Aug 07 20:58:53 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 03 04:06:10 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 09 02:55:35 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 18 01:24:41 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Dec 01 04:29:17 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Dec 16 21:08:06 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 03 00:35:29 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 03 00:36:33 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system 00srv:~ # ll /var/log/m* ls: cannot access '/var/log/m*': No such file or directory # -- Evolution as taught in public schools, like religion, is based on faith, not on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/11/2020 03.22, Felix Miata wrote:
Carlos E. R. composed on 2020-11-07 02:55 (UTC+0100):
The problem is finding out when the timer did run and what was the result, if any.
Perhaps try "journalctl | grep fstrim" or "grep -i fstrim /var/log/messages", which in my case both return empty.
So I try "zgrep -i fstrim /var/log/messages*z" which does return things. The last entries (October) are:
# journalctl | grep -i trim Aug 03 02:08:01 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Aug 03 03:25:04 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Aug 07 20:58:53 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 03 04:06:10 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 09 02:55:35 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 18 01:24:41 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Dec 01 04:29:17 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Dec 16 21:08:06 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 03 00:35:29 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 03 00:36:33 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system
For some reason, the journal doesn't log fstrim entries, I infer.
00srv:~ # ll /var/log/m* ls: cannot access '/var/log/m*': No such file or directory #
And you must be using TW, which does not run a syslog daemon. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Sunday 08 November 2020, Carlos E. R. wrote:
On 07/11/2020 03.22, Felix Miata wrote:
Carlos E. R. composed on 2020-11-07 02:55 (UTC+0100):
The problem is finding out when the timer did run and what was the result, if any.
Perhaps try "journalctl | grep fstrim" or "grep -i fstrim /var/log/messages", which in my case both return empty.
So I try "zgrep -i fstrim /var/log/messages*z" which does return things. The last entries (October) are:
# journalctl | grep -i trim Aug 03 02:08:01 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Aug 03 03:25:04 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Aug 07 20:58:53 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 03 04:06:10 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 09 02:55:35 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 18 01:24:41 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Dec 01 04:29:17 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Dec 16 21:08:06 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 03 00:35:29 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system Nov 03 00:36:33 00srv systemd[1]: Failed to trim compat systemd cgroup /user.slice: Read-only file system
For some reason, the journal doesn't log fstrim entries, I infer.
00srv:~ # ll /var/log/m* ls: cannot access '/var/log/m*': No such file or directory #
And you must be using TW, which does not run a syslog daemon.
On TW just now (with ext4 for all ssd file systems, including root): kosmos1:~ # journalctl | grep fstrim | tail Nov 04 13:35:23 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 04 22:24:05 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 11:50:43 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 12:22:59 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 12:41:55 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 12:44:00 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 22:56:48 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 06 09:26:08 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 06 22:55:33 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 07 23:17:14 kosmos1 systemd[1]: fstrim.timer: Succeeded. So if it's running on TW, you should at least see the above in the journal. Michael -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/11/2020 00.31, Michael Hamilton wrote:
On Sunday 08 November 2020, Carlos E. R. wrote:
On 07/11/2020 03.22, Felix Miata wrote:
Carlos E. R. composed on 2020-11-07 02:55 (UTC+0100):
On TW just now (with ext4 for all ssd file systems, including root):
kosmos1:~ # journalctl | grep fstrim | tail Nov 04 13:35:23 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 04 22:24:05 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 11:50:43 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 12:22:59 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 12:41:55 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 12:44:00 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 22:56:48 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 06 09:26:08 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 06 22:55:33 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 07 23:17:14 kosmos1 systemd[1]: fstrim.timer: Succeeded.
So if it's running on TW, you should at least see the above in the journal.
I don't - on Leap 15.1: Telcontar:~ # journalctl | grep fstrim Telcontar:~ # grep -i fstrim /var/log/messages Telcontar:~ # zgrep -i fstrim /var/log/messages*z | tail /var/log/messages-20200724.xz:<3.6> 2020-07-20T00:00:43.346392+02:00 Telcontar fstrim 9471 - - /: 100.8 GiB (108246233088 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20200811.xz:Binary file (standard input) matches /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.339977+02:00 Telcontar fstrim 7949 - - /other/auxiliary: 18.2 GiB (19561299968 bytes) trimmed on /dev/nvme0n1p3 /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.340336+02:00 Telcontar fstrim 7949 - - /boot: 883.5 MiB (926412800 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.340461+02:00 Telcontar fstrim 7949 - - /: 99.5 GiB (106817015808 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724242+02:00 Telcontar fstrim 917 - - /other/auxiliary: 0 B (0 bytes) trimmed on /dev/nvme0n1p3 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724504+02:00 Telcontar fstrim 917 - - /boot: 208.3 MiB (218365952 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724647+02:00 Telcontar fstrim 917 - - /: 18.5 GiB (19850489856 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20201026.xz:<3.6> 2020-10-19T00:00:41.576785+02:00 Telcontar fstrim 5779 - - /boot: 936.5 MiB (981962752 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201026.xz:<3.6> 2020-10-19T00:00:41.577034+02:00 Telcontar fstrim 5779 - - /: 99.4 GiB (106693591040 bytes) trimmed on /dev/nvme0n1p5 Telcontar:~ # The timer is enabled: Telcontar:~ # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Fri 2020-10-16 13:26:11 CEST; 3 weeks 1 days ago Trigger: Mon 2020-11-09 00:00:00 CET; 22h left Docs: man:fstrim Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. Telcontar:~ # Rotated? Telcontar:~ # journalctl | head -- Logs begin at Sun 2020-08-09 14:33:00 CEST, end at Sun 2020-11-08 01:48:08 CET. -- Aug 09 14:33:00 Telcontar openvpn[31753]: UID set to nobody Why syslog has information that journal doesn't have, I have no idea. Why no entries since October 26, no idea. More than a week has passed. If I were to guess, the systemd timer doesn't trigger if the machine is not up and running at the exact time it wants to run. Quite unreliable. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
In data domenica 8 novembre 2020 01:53:52 CET, Carlos E. R. ha scritto:
On 08/11/2020 00.31, Michael Hamilton wrote:
On Sunday 08 November 2020, Carlos E. R. wrote:
On 07/11/2020 03.22, Felix Miata wrote:
Carlos E. R. composed on 2020-11-07 02:55 (UTC+0100): On TW just now (with ext4 for all ssd file systems, including root):
kosmos1:~ # journalctl | grep fstrim | tail Nov 04 13:35:23 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 04 22:24:05 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 11:50:43 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 12:22:59 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 12:41:55 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 12:44:00 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 05 22:56:48 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 06 09:26:08 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 06 22:55:33 kosmos1 systemd[1]: fstrim.timer: Succeeded. Nov 07 23:17:14 kosmos1 systemd[1]: fstrim.timer: Succeeded.
So if it's running on TW, you should at least see the above in the journal.
I don't - on Leap 15.1:
Telcontar:~ # journalctl | grep fstrim Telcontar:~ # grep -i fstrim /var/log/messages Telcontar:~ # zgrep -i fstrim /var/log/messages*z | tail /var/log/messages-20200724.xz:<3.6> 2020-07-20T00:00:43.346392+02:00 Telcontar fstrim 9471 - - /: 100.8 GiB (108246233088 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20200811.xz:Binary file (standard input) matches /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.339977+02:00 Telcontar fstrim 7949 - - /other/auxiliary: 18.2 GiB (19561299968 bytes) trimmed on /dev/nvme0n1p3 /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.340336+02:00 Telcontar fstrim 7949 - - /boot: 883.5 MiB (926412800 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.340461+02:00 Telcontar fstrim 7949 - - /: 99.5 GiB (106817015808 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724242+02:00 Telcontar fstrim 917 - - /other/auxiliary: 0 B (0 bytes) trimmed on /dev/nvme0n1p3 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724504+02:00 Telcontar fstrim 917 - - /boot: 208.3 MiB (218365952 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724647+02:00 Telcontar fstrim 917 - - /: 18.5 GiB (19850489856 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20201026.xz:<3.6> 2020-10-19T00:00:41.576785+02:00 Telcontar fstrim 5779 - - /boot: 936.5 MiB (981962752 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201026.xz:<3.6> 2020-10-19T00:00:41.577034+02:00 Telcontar fstrim 5779 - - /: 99.4 GiB (106693591040 bytes) trimmed on /dev/nvme0n1p5 Telcontar:~ #
The timer is enabled:
Telcontar:~ # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Fri 2020-10-16 13:26:11 CEST; 3 weeks 1 days ago Trigger: Mon 2020-11-09 00:00:00 CET; 22h left Docs: man:fstrim
Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. Telcontar:~ #
Rotated?
Telcontar:~ # journalctl | head -- Logs begin at Sun 2020-08-09 14:33:00 CEST, end at Sun 2020-11-08 01:48:08 CET. -- Aug 09 14:33:00 Telcontar openvpn[31753]: UID set to nobody
Why syslog has information that journal doesn't have, I have no idea.
Why no entries since October 26, no idea. More than a week has passed. If I were to guess, the systemd timer doesn't trigger if the machine is not up and running at the exact time it wants to run.
Quite unreliable. entropia@roadrunner:~> sudo service fstrim.timer status service: no such service fstrim.timer
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 08/11/2020 05.20, Stakanov wrote:
In data domenica 8 novembre 2020 01:53:52 CET, Carlos E. R. ha scritto:
entropia@roadrunner:~> sudo service fstrim.timer status service: no such service fstrim.timer
It is not a service. Use "systemctl status fstrim.timer" -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Monday 09 November 2020, Carlos E.R. wrote:
On 08/11/2020 05.20, Stakanov wrote:
In data domenica 8 novembre 2020 01:53:52 CET, Carlos E. R. ha scritto:
entropia@roadrunner:~> sudo service fstrim.timer status service: no such service fstrim.timer
It is not a service.
Use "systemctl status fstrim.timer"
Well there is a kind of service, it's run periodically by the timer, so you can also do: systemctl status fstrim.service And the output will be something like ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static) Active: inactive (dead) since Mon 2020-11-09 12:55:18 NZDT; 1h 15min ago TriggeredBy: ● fstrim.timer Docs: man:fstrim(8) Main PID: 1217 (code=exited, status=0/SUCCESS) Nov 09 12:55:18 kosmos1 systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab... Nov 09 12:55:18 kosmos1 systemd[1]: fstrim.service: Succeeded. Nov 09 12:55:18 kosmos1 systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab. So in my case it last ran successfully today. Cheers, Michael -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 09/11/2020 02.14, Michael Hamilton wrote:
On Monday 09 November 2020, Carlos E.R. wrote:
On 08/11/2020 05.20, Stakanov wrote:
In data domenica 8 novembre 2020 01:53:52 CET, Carlos E. R. ha scritto:
entropia@roadrunner:~> sudo service fstrim.timer status service: no such service fstrim.timer
It is not a service.
Use "systemctl status fstrim.timer"
Well there is a kind of service, it's run periodically by the timer, so you can also do:
But Stakanov issued the command "service" on "fstrim.timer", which is not a service, it is a timer. He did not run the command "service" on "fstrim.service". He did not issue "sudo service fstrim status", which would have worked.
systemctl status fstrim.service
And the output will be something like ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static) Active: inactive (dead) since Mon 2020-11-09 12:55:18 NZDT; 1h 15min ago TriggeredBy: ● fstrim.timer Docs: man:fstrim(8) Main PID: 1217 (code=exited, status=0/SUCCESS)
Nov 09 12:55:18 kosmos1 systemd[1]: Starting Discard unused blocks on filesystems from /etc/fstab... Nov 09 12:55:18 kosmos1 systemd[1]: fstrim.service: Succeeded. Nov 09 12:55:18 kosmos1 systemd[1]: Finished Discard unused blocks on filesystems from /etc/fstab.
So in my case it last ran successfully today.
Telcontar:~ # systemctl status fstrim.service ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) since Mon 2020-10-19 00:00:41 CEST; 3 weeks 0 days ago Docs: man:fstrim(8) Main PID: 5779 (code=exited, status=0/SUCCESS) Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable. Telcontar:~ # Inactive 3 weeks ago, which is more or less my uptime: Telcontar:~ # uptime 02:34:49 up 23 days 14:08, 3 users, load average: 0.49, 0.56, 0.45 Telcontar:~ # It also says that the journal has been rotated since unit was started. This is not true: Telcontar:~ # journalctl | head -- Logs begin at Sun 2020-08-09 14:33:00 CEST, end at Mon 2020-11-09 02:35:20 CET. -- Aug 09 14:33:00 Telcontar openvpn[31753]: UID set to nobody Aug 09 14:33:00 Telcontar openvpn[31753]: Initialization Sequence Completed so the journal logs start on August, way way before the unit was started. Also the journal claims that the timer has never triggered: Telcontar:~ # journalctl | grep fstrim Telcontar:~ # Which is not true, there is record of it in syslog: although not recently: Telcontar:~ # grep -i fstrim /var/log/messages Telcontar:~ # But 21 days ago: Telcontar:~ # zgrep -i fstrim /var/log/messages*z | tail /var/log/messages-20200724.xz:<3.6> 2020-07-20T00:00:43.346392+02:00 Telcontar fstrim 9471 - - /: 100.8 GiB (108246233088 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20200811.xz:Binary file (standard input) matches /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.339977+02:00 Telcontar fstrim 7949 - - /other/auxiliary: 18.2 GiB (19561299968 bytes) trimmed on /dev/nvme0n1p3 /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.340336+02:00 Telcontar fstrim 7949 - - /boot: 883.5 MiB (926412800 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201008.xz:<3.6> 2020-09-21T00:00:42.340461+02:00 Telcontar fstrim 7949 - - /: 99.5 GiB (106817015808 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724242+02:00 Telcontar fstrim 917 - - /other/auxiliary: 0 B (0 bytes) trimmed on /dev/nvme0n1p3 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724504+02:00 Telcontar fstrim 917 - - /boot: 208.3 MiB (218365952 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201008.xz:<3.6> 2020-09-28T00:00:13.724647+02:00 Telcontar fstrim 917 - - /: 18.5 GiB (19850489856 bytes) trimmed on /dev/nvme0n1p5 /var/log/messages-20201026.xz:<3.6> 2020-10-19T00:00:41.576785+02:00 Telcontar fstrim 5779 - - /boot: 936.5 MiB (981962752 bytes) trimmed on /dev/nvme0n1p4 /var/log/messages-20201026.xz:<3.6> 2020-10-19T00:00:41.577034+02:00 Telcontar fstrim 5779 - - /: 99.4 GiB (106693591040 bytes) trimmed on /dev/nvme0n1p5 Telcontar:~ # So. Questions: 1) Why hasn't fstrim run in three weeks in my system? 2) Why are the events not registered by the journal? 3) Maybe if the machine is not running precisely Mondays at 00 hours, it doesn't work. Very unreliable. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 09/11/2020 02.57, Carlos E. R. wrote:
On 09/11/2020 02.14, Michael Hamilton wrote:
On Monday 09 November 2020, Carlos E.R. wrote:
On 08/11/2020 05.20, Stakanov wrote:
In data domenica 8 novembre 2020 01:53:52 CET, Carlos E. R. ha scritto:
...
So. Questions:
1) Why hasn't fstrim run in three weeks in my system?
2) Why are the events not registered by the journal?
3) Maybe if the machine is not running precisely Mondays at 00 hours, it doesn't work.
Very unreliable.
On another machine, upgraded today to 15.2: minas-tirith:~ # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Sun 2020-11-08 12:18:16 CET; 14h ago Trigger: Mon 2020-11-16 00:00:00 CET; 6 days left Docs: man:fstrim minas-tirith:~ # minas-tirith:~ # service fstrim status ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) since Mon 2020-11-09 00:01:35 CET; 3h 11min ago Docs: man:fstrim(8) Process: 20497 ExecStart=/usr/sbin/fstrim -Av (code=exited, status=0/SUCCESS) Main PID: 20497 (code=exited, status=0/SUCCESS) minas-tirith:~ # So it triggered 3 hours ago. Let's see the journal: minas-tirith:~ # journalctl | grep fstrim minas-tirith:~ # nothing. Syslog? minas-tirith:~ # grep -i fstrim /var/log/messages <3.6> 2020-11-09 00:01:35 minas-tirith fstrim 20497 - - /other: 1.6 GiB (1716981760 bytes) trimmed on /dev/sda9 <3.6> 2020-11-09 00:01:35 minas-tirith fstrim 20497 - - /: 5.1 GiB (5511180288 bytes) trimmed on /dev/sda7 <3.6> 2020-11-09 00:01:35 minas-tirith fstrim 20497 - - /boot: 113.7 MiB (119165952 bytes) trimmed on /dev/sda6 minas-tirith:~ # Why is the journal silent about this event? -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
09.11.2020 05:22, Carlos E. R. пишет:
On 09/11/2020 02.57, Carlos E. R. wrote:
On 09/11/2020 02.14, Michael Hamilton wrote:
On Monday 09 November 2020, Carlos E.R. wrote:
On 08/11/2020 05.20, Stakanov wrote:
In data domenica 8 novembre 2020 01:53:52 CET, Carlos E. R. ha scritto:
...
So. Questions:
1) Why hasn't fstrim run in three weeks in my system?
2) Why are the events not registered by the journal?
3) Maybe if the machine is not running precisely Mondays at 00 hours, it doesn't work.
Very unreliable.
On another machine, upgraded today to 15.2:
minas-tirith:~ # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Sun 2020-11-08 12:18:16 CET; 14h ago Trigger: Mon 2020-11-16 00:00:00 CET; 6 days left Docs: man:fstrim minas-tirith:~ #
minas-tirith:~ # service fstrim status ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) since Mon 2020-11-09 00:01:35 CET; 3h 11min ago Docs: man:fstrim(8) Process: 20497 ExecStart=/usr/sbin/fstrim -Av (code=exited, status=0/SUCCESS) Main PID: 20497 (code=exited, status=0/SUCCESS) minas-tirith:~ #
So it triggered 3 hours ago. Let's see the journal:
minas-tirith:~ # journalctl | grep fstrim minas-tirith:~ #
nothing. Syslog?
minas-tirith:~ # grep -i fstrim /var/log/messages <3.6> 2020-11-09 00:01:35 minas-tirith fstrim 20497 - - /other: 1.6 GiB (1716981760 bytes) trimmed on /dev/sda9 <3.6> 2020-11-09 00:01:35 minas-tirith fstrim 20497 - - /: 5.1 GiB (5511180288 bytes) trimmed on /dev/sda7 <3.6> 2020-11-09 00:01:35 minas-tirith fstrim 20497 - - /boot: 113.7 MiB (119165952 bytes) trimmed on /dev/sda6 minas-tirith:~ #
Why is the journal silent about this event?
Did you disable persistent journal?
On 09/11/2020 06.49, Andrei Borzenkov wrote:
09.11.2020 05:22, Carlos E. R. пишет:
On 09/11/2020 02.57, Carlos E. R. wrote:
On 09/11/2020 02.14, Michael Hamilton wrote:
On Monday 09 November 2020, Carlos E.R. wrote:
On 08/11/2020 05.20, Stakanov wrote:
In data domenica 8 novembre 2020 01:53:52 CET, Carlos E. R. ha scritto:
...
So. Questions:
1) Why hasn't fstrim run in three weeks in my system?
2) Why are the events not registered by the journal?
3) Maybe if the machine is not running precisely Mondays at 00 hours, it doesn't work.
Very unreliable.
On another machine, upgraded today to 15.2:
minas-tirith:~ # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Sun 2020-11-08 12:18:16 CET; 14h ago Trigger: Mon 2020-11-16 00:00:00 CET; 6 days left Docs: man:fstrim minas-tirith:~ #
minas-tirith:~ # service fstrim status ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) since Mon 2020-11-09 00:01:35 CET; 3h 11min ago Docs: man:fstrim(8) Process: 20497 ExecStart=/usr/sbin/fstrim -Av (code=exited, status=0/SUCCESS) Main PID: 20497 (code=exited, status=0/SUCCESS) minas-tirith:~ #
So it triggered 3 hours ago. Let's see the journal:
minas-tirith:~ # journalctl | grep fstrim minas-tirith:~ #
nothing. Syslog?
minas-tirith:~ # grep -i fstrim /var/log/messages <3.6> 2020-11-09 00:01:35 minas-tirith fstrim 20497 - - /other: 1.6 GiB (1716981760 bytes) trimmed on /dev/sda9 <3.6> 2020-11-09 00:01:35 minas-tirith fstrim 20497 - - /: 5.1 GiB (5511180288 bytes) trimmed on /dev/sda7 <3.6> 2020-11-09 00:01:35 minas-tirith fstrim 20497 - - /boot: 113.7 MiB (119165952 bytes) trimmed on /dev/sda6 minas-tirith:~ #
Why is the journal silent about this event?
Did you disable persistent journal?
No; as you can see the journal starts on August, and the uptime was two or three weeks. I have no access to that system now, it doesn't boot. I can not verify things. I'm booted on a different partition (still 15.1), and it has run this morning. Still, nothing in the journal. Andor:~ # systemctl status fstrim ● fstrim.service - Discard unused blocks on filesystems from /etc/fstab Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) Docs: man:fstrim(8) Andor:~ # systemctl status fstrim.timer ● fstrim.timer - Discard unused blocks once a week Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled) Active: active (waiting) since Mon 2020-11-09 11:48:36 CET; 1h 5min ago Trigger: Mon 2020-11-16 00:00:00 CET; 6 days left Docs: man:fstrim Nov 09 11:48:36 Andor systemd[1]: Started Discard unused blocks once a week. Andor:~ # journalctl | grep fstrim Andor:~ # grep -i fstrim /var/log/messages 2020-11-09T11:37:58.756763+01:00 Andor fstrim[1892]: /other/main/boot: 936.5 MiB (981962752 bytes) trimmed on /dev/nvme0n1p4 2020-11-09T11:37:58.756959+01:00 Andor fstrim[1892]: /other/main: 99.7 GiB (107044753408 bytes) trimmed on /dev/nvme0n1p5 2020-11-09T11:37:58.757071+01:00 Andor fstrim[1892]: /: 18.2 GiB (19542855680 bytes) trimmed on /dev/nvme0n1p3 Andor:~ # -- Cheers. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 6 novembre 2020 06:36:06 CET, Felix Miata ha scritto:
Both SSD 120G: PNY SSD7CS900-120-RB bought 2018-07-21, died March 2019, replaced under warranty. Mushkin MKNSSDSR120GB bought 2018-06.21, being replaced under warranty, died Monday during 'zypper dup' from 15.0 to 15.2 on 18000 MiB partition.
I really have no idea the runtime on either, as I sometimes clone whole disks (both HDD & SSD) as backup routine, and sometimes only partitions. The Mushkin was in continuous service for about 10 months ~24/7 with noatime as a mount option, and fstrim run weekly. I have 2 other 120G SSDs, a Crucial BX500 and an Adata XPG, that have been in my clone rotation on this PC. These SSDs are MBR partitioned and used only for /boot 1.2G, /usr/local/ 4G, a 16G swap not often enabled (and never enabled since I raised RAM to 32G), and 5 18G OS partitions (13.1, 15.0, 15.1, 15.2 & TW, with 15.1 in majority of use since 2019-12-26).
What I'm guessing is I've gotten on average well under 10 month's service out of each before failure, considering I only bought my first SSD 29 months ago.
My /home, /tmp and other user data are on rotating rust RAID1.
Has anyone here had worse experience? Any suggestions to do something differently? Some stupid question: didn't you have smart support running on them? No prior warning before the event? Especially extended test show you the "worst or highest temperature" ever encountered in service of the disc, which is IMO (member of the unwashed masses) a better indicator if you have periods of temperature stress.
PSU can be a culprit (as it has been mentioned). Something that happened to me twice now in the last 30 years (not often but still): counterfeit refurbished hardware sold as new. Happened to me in Italy with Samsung discs and also with Seagate discs (were HDD at the time). The way they were sold, you would have never seen the problem. But the time to failure was short, so a lot of people at the time complained. I found out by chance because only the material that I bought in Italy failed at that time, the German supplied parts didn't. Do not say happens to you, but maybe consider to try to change supplier with one disc to see if this happens still or "magically" changes? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/7/20 1:30 AM, Stakanov wrote:
Something that happened to me twice now in the last 30 years (not often but still): counterfeit refurbished hardware sold as new. Happened to me in Italy with Samsung discs and also with Seagate discs (were HDD at the time). The way they were sold, you would have never seen the problem. But the time to failure was short, so a lot of people at the time complained. I found out by chance because only the material that I bought in Italy failed at that time, the German supplied parts didn't. Do not say happens to you, but maybe consider to try to change supplier with one disc to see if this happens still or "magically" changes?
The Security Now podcast had counterfeit network equipment as a topic not too long ago. It's at the end of this transcript and is interesting. https://www.grc.com/sn/sn-776-notes.pdf The article has photos showing the fake and the real, and how difficult it is to differentiate. I think that suspect drives can be confirmed genuine if there are suspicions, it looks like there are programs for Seagate and Samsung to detect counterfeits. https://tipsmake.com/how-to-identify-ssd-hard-drive-is-real-or-fake Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Andrei Borzenkov -
Carl Hartung -
Carlos E. R. -
Carlos E.R. -
David C. Rankin -
Felix Miata -
Lew Wolfgang -
Michael Hamilton -
Stakanov