[opensuse-support] Overall 42.3 responsiveness way down. SSD going/gone bad?
# cat /proc/mdstat Personalities : [raid1] md5 : active raid1 sdb10[0] sdc10[2] 655359808 blocks super 1.0 [2/2] [UU] bitmap: 0/5 pages [0KB], 65536KB chunk md1 : active raid1 sdb6[0] sdc6[2] 4095936 blocks super 1.0 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md4 : active raid1 sdc9[2] sdb9[0] 217087808 blocks super 1.0 [2/2] [UU] bitmap: 0/2 pages [0KB], 65536KB chunk md3 : active raid1 sdc8[2] sdb8[0] 73727872 blocks super 1.0 [2/2] [UU] bitmap: 1/1 pages [4KB], 65536KB chunk md2 : active raid1 sdc7[2] sdb7[0] 8191936 blocks super 1.0 [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk md0 : active raid1 sdb5[0] sdc5[2] 8834944 blocks super 1.0 [2/2] [UU] bitmap: 1/1 pages [4KB], 65536KB chunk unused devices: <none> # df -lhT Filesystem Type Size Used Avail Use% Mounted on /dev/sda10 ext4 18G 7.8G 8.7G 48% / /dev/sda3 ext2 1.2G 641M 550M 54% /disks/boot /dev/md3 ext4 70G 26G 44G 38% /home /dev/md0 ext4 8.4G 1.7G 6.3G 21% /tmp /dev/md1 ext4 3.9G 1.7G 2.2G 43% /usr/local /dev/md4 ext4 206G 119G 88G 58% /private /dev/md2 ext4 7.8G 1.8G 6.0G 23% /srv /dev/md5 ext4 620G 422G 199G 68% /secret # fstrim -av /disks/boot: 0 B (0 bytes) trimmed /: 0 B (0 bytes) trimmed # grep -i trim /etc/fstab # parted -l Model: ATA PNY CS900 120GB (scsi) Disk /dev/sda: 120GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 264MB 263MB primary fat16 type=06 2 264MB 2781MB 2517MB primary hidden, type=17 3 2781MB 4039MB 1258MB primary ext2 boot, type=83 4 4039MB 120GB 116GB extended type=05 5 4039MB 21.5GB 17.4GB logical linux-swap(v1) type=82 6 21.5GB 25.7GB 4194MB logical ext3 type=83 7 25.7GB 44.5GB 18.9GB logical ext4 type=83 8 44.5GB 63.4GB 18.9GB logical ext4 type=83 9 63.4GB 82.3GB 18.9GB logical ext4 type=83 10 82.3GB 101GB 18.9GB logical ext4 type=83 11 101GB 120GB 18.9GB logical ext4 type=83 # hdparm -tT /dev/sda /dev/sdb /dev/sdc /dev/sda: Timing cached reads: 13988 MB in 2.00 seconds = 7010.44 MB/sec Timing buffered disk reads: 22 MB in 3.10 seconds = 7.09 MB/sec /dev/sdb: Timing cached reads: 14114 MB in 2.00 seconds = 7074.17 MB/sec Timing buffered disk reads: 358 MB in 3.01 seconds = 118.77 MB/sec /dev/sdc: Timing cached reads: 14530 MB in 1.99 seconds = 7283.44 MB/sec Timing buffered disk reads: 406 MB in 3.02 seconds = 134.23 MB/sec # smartctl -t long /dev/sda ... Testing has begun. Please wait 30 minutes for test to complete. ... # smartctl -a /dev/sda smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.165-81-default] (SUSE RPM) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Device Model: PNY CS900 120GB SSD Serial Number: PNY06182239150108A56 LU WWN Device Id: 5 f8db4c 061808a56 Firmware Version: CS900612 User Capacity: 120,034,123,776 bytes [120 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Form Factor: 2.5 inches Device is: Not in smartctl database [for details use: -P showall] ATA Version is: Unknown(0x0ff8) (minor revision not indicated) SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Thu Feb 21 12:12:21 2019 EST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (65535) seconds. Offline data collection capabilities: (0x79) SMART execute Offline immediate. No Auto Offline data collection support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 30) minutes. Conveyance self-test routine recommended polling time: ( 6) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0 9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 4244 12 Power_Cycle_Count 0x0012 100 100 000 Old_age Always - 172 168 Unknown_Attribute 0x0012 100 100 000 Old_age Always - 0 170 Unknown_Attribute 0x0003 088 088 000 Pre-fail Always - 134 173 Unknown_Attribute 0x0012 100 100 000 Old_age Always - 262151 192 Power-Off_Retract_Count 0x0012 100 100 000 Old_age Always - 128 194 Temperature_Celsius 0x0023 067 067 000 Pre-fail Always - 33 (Min/Max 33/33) 218 Unknown_Attribute 0x000b 100 100 050 Pre-fail Always - 0 231 Temperature_Celsius 0x0013 100 100 000 Pre-fail Always - 99 241 Total_LBAs_Written 0x0012 100 100 000 Old_age Always - 110 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 4244 - # 2 Extended offline Completed without error 00% 3802 - # 3 Extended offline Interrupted (host reset) 00% 3777 - # 4 Extended offline Completed without error 00% 3130 - # 5 Extended offline Completed without error 00% 2291 - # 6 Extended offline Completed without error 00% 1748 - # 7 Extended offline Completed without error 00% 1620 - # 8 Extended offline Completed without error 00% 1619 - # 9 Extended offline Completed without error 00% 1204 - #10 Extended offline Completed without error 00% 948 - #11 Extended offline Completed without error 00% 109 - #12 Short offline Completed without error 00% 46 - #13 Short offline Completed without error 00% 40 - #14 Short offline Completed without error 00% 36 - #15 Extended offline Completed without error 00% 35 - #16 Short offline Completed without error 00% 26 - #17 Short offline Interrupted (host reset) 00% 24 - SMART Selective self-test log data structure revision number 0 Note: revision number not 1 implies that no selective self-test has ever been run SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. /dev/sda was new in July 2018. What should I do next? -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 21/02/2019 18.31, Felix Miata wrote: ...
# hdparm -tT /dev/sda /dev/sdb /dev/sdc
/dev/sda: Timing cached reads: 13988 MB in 2.00 seconds = 7010.44 MB/sec Timing buffered disk reads: 22 MB in 3.10 seconds = 7.09 MB/sec
This one does seem very slow, and it is not part of the raids. Maybe it is busy, something is using it heavily. SSD, you say?
/dev/sdb: Timing cached reads: 14114 MB in 2.00 seconds = 7074.17 MB/sec Timing buffered disk reads: 358 MB in 3.01 seconds = 118.77 MB/sec
This one is a trifle slow, compared to the other.
/dev/sdc: Timing cached reads: 14530 MB in 1.99 seconds = 7283.44 MB/sec Timing buffered disk reads: 406 MB in 3.02 seconds = 134.23 MB/sec # smartctl -t long /dev/sda ... Testing has begun. Please wait 30 minutes for test to complete. ... # smartctl -a /dev/sda smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.165-81-default] (SUSE RPM) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION === Device Model: PNY CS900 120GB SSD Serial Number: PNY06182239150108A56 LU WWN Device Id: 5 f8db4c 061808a56 Firmware Version: CS900612 User Capacity: 120,034,123,776 bytes [120 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Form Factor: 2.5 inches Device is: Not in smartctl database [for details use: -P showall] ATA Version is: Unknown(0x0ff8) (minor revision not indicated) SATA Version is: SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s) Local Time is: Thu Feb 21 12:12:21 2019 EST SMART support is: Available - device has SMART capability. SMART support is: Enabled
Does not say it is SSD, and has few fields. ...
SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 100 100 050 Pre-fail Always - 0 9 Power_On_Hours 0x0012 100 100 000 Old_age Always - 4244 12 Power_Cycle_Count 0x0012 100 100 000 Old_age Always - 172 168 Unknown_Attribute 0x0012 100 100 000 Old_age Always - 0 170 Unknown_Attribute 0x0003 088 088 000 Pre-fail Always - 134
This is the only value that is starting to go bad, but we don't know what it is.
173 Unknown_Attribute 0x0012 100 100 000 Old_age Always - 262151 192 Power-Off_Retract_Count 0x0012 100 100 000 Old_age Always - 128 194 Temperature_Celsius 0x0023 067 067 000 Pre-fail Always - 33 (Min/Max 33/33) 218 Unknown_Attribute 0x000b 100 100 050 Pre-fail Always - 0 231 Temperature_Celsius 0x0013 100 100 000 Pre-fail Always - 99 241 Total_LBAs_Written 0x0012 100 100 000 Old_age Always - 110
It does not say how much life is left. The Total_LBAs_Written count is absurd. Compare with one of mine: SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 6801 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 545 177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 14 179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0 181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0 182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0 183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0 187 Uncorrectable_Error_Cnt 0x0032 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0032 078 055 000 Old_age Always - 22 195 ECC_Error_Rate 0x001a 200 200 000 Old_age Always - 0 199 CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0 235 POR_Recovery_Count 0x0012 099 099 000 Old_age Always - 20 241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 8199006662 There are fields that have to do with being an SSD. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. composed on 2019-02-21 18:53 (UTC+0100):
Felix Miata wrote:
# hdparm -tT /dev/sda /dev/sdb /dev/sdc
/dev/sda: Timing cached reads: 13988 MB in 2.00 seconds = 7010.44 MB/sec Timing buffered disk reads: 22 MB in 3.10 seconds = 7.09 MB/sec
This one does seem very slow, and it is not part of the raids. Maybe it is busy, something is using it heavily. SSD, you say?
https://www.newegg.com/Product/Product.aspx?Item=N82E16820177029
/dev/sdb: Timing cached reads: 14114 MB in 2.00 seconds = 7074.17 MB/sec Timing buffered disk reads: 358 MB in 3.01 seconds = 118.77 MB/sec
This one is a trifle slow, compared to the other.
I noticed that when they were brand new last summer.
/dev/sdc: Timing cached reads: 14530 MB in 1.99 seconds = 7283.44 MB/sec Timing buffered disk reads: 406 MB in 3.02 seconds = 134.23 MB/sec # smartctl -t long /dev/sda ... Testing has begun. Please wait 30 minutes for test to complete. ... # smartctl -a /dev/sda smartctl 6.5 2016-05-07 r4318 [x86_64-linux-4.4.165-81-default] (SUSE RPM) Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION === Device Model: PNY CS900 120GB SSD ... Rotation Rate: Solid State Device ... Does not say it is SSD
Are you sure? Besides that, I have my doubts PNY ever made or sold any type of storage that wasn't solid state.
170 Unknown_Attribute 0x0003 088 088 000 Pre-fail Always - 134
This is the only value that is starting to go bad, but we don't know what it is.
Could be nonsense from poor firmware I suppose.
241 Total_LBAs_Written 0x0012 100 100 000 Old_age Always - 110
It does not say how much life is left. The Total_LBAs_Written count is absurd.
No doubt. The question remaining is what next to do? I emailed the PNY support address I found in the Newegg reviews after starting this thread. No response as yet. Speed is marginally better logged out of KDE, but rather erratic in percent, not improved by fresh boot, nominally different in TW & 15.0 and definitely dismal compared to the rotating rust. These are all from 42.3: Timing buffered disk reads: 28 MB in 3.27 seconds = 8.56 MB/sec Timing buffered disk reads: 24 MB in 3.19 seconds = 7.53 MB/sec Timing buffered disk reads: 26 MB in 3.16 seconds = 8.23 MB/sec Timing buffered disk reads: 26 MB in 3.22 seconds = 8.07 MB/sec Timing buffered disk reads: 24 MB in 3.37 seconds = 7.12 MB/sec Timing buffered disk reads: 24 MB in 3.23 seconds = 7.42 MB/sec When it was new last summer: Timing buffered disk reads: 770 MB in 3.00 seconds = 256.62 MB/sec :~( -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 22/02/2019 09.11, Felix Miata wrote:
Carlos E. R. composed on 2019-02-21 18:53 (UTC+0100):
=== START OF INFORMATION SECTION === Device Model: PNY CS900 120GB SSD ... Rotation Rate: Solid State Device ... Does not say it is SSD
Ah, now I notice it in the model name.
Are you sure? Besides that, I have my doubts PNY ever made or sold any type of storage that wasn't solid state.
No parameters related to ssd, like Wear_Leveling_Count
170 Unknown_Attribute 0x0003 088 088 000 Pre-fail Always - 134
This is the only value that is starting to go bad, but we don't know what it is.
Could be nonsense from poor firmware I suppose.
No, it means that smartctl doesn't know about it. Maybe a more current version would know. Here: <https://www.thomas-krenn.com/en/wiki/SMART_attributes_of_Intel_SSDs> AA 170 Available Reserved Space Reports the number of reserve blocks remaining. The normalized value begins at 100 (64h), which corresponds to 100 percent availability of the reserved space. The threshold value for this attribute is 10 percent availability. So it is going down indeed. It is aging.
241 Total_LBAs_Written 0x0012 100 100 000 Old_age Always - 110
It does not say how much life is left. The Total_LBAs_Written count is absurd.
No doubt.
The question remaining is what next to do?
Maybe it needs trim. Do systemctl status fstrim In mine: Isengard:~ # systemctl status fstrim ● fstrim.service - Discard unused blocks Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) since Mon 2019-02-11 00:01:33 CET; 1 weeks 4 days ago Process: 11202 ExecStart=/usr/sbin/fstrim -av (code=exited, status=0/SUCCESS) Main PID: 11202 (code=exited, status=0/SUCCESS) Feb 11 00:00:01 Isengard systemd[1]: Starting Discard unused blocks... Feb 11 00:01:33 Isengard fstrim[11202]: /: 2.5 GiB (2707025920 bytes) trimmed Feb 11 00:01:33 Isengard systemd[1]: Started Discard unused blocks. Isengard:~ # There should be a timer: /usr/lib/systemd/system/fstrim.timer So: Isengard:~ # 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 2018-12-30 22:58:50 CET; 1 months 23 days ago Trigger: Mon 2019-02-25 00:00:00 CET; 2 days left Docs: man:fstrim Dec 30 22:58:50 Isengard systemd[1]: Started Discard unused blocks once a week. Isengard:~ # And then, you can grep the syslog grep -i "discard\|trim" /var/log/messages or journalctl | grep -i "discard\|trim"
I emailed the PNY support address I found in the Newegg reviews after starting this thread. No response as yet. Speed is marginally better logged out of KDE, but rather erratic in percent, not improved by fresh boot, nominally different in TW & 15.0 and definitely dismal compared to the rotating rust. These are all from 42.3:
Timing buffered disk reads: 28 MB in 3.27 seconds = 8.56 MB/sec Timing buffered disk reads: 24 MB in 3.19 seconds = 7.53 MB/sec Timing buffered disk reads: 26 MB in 3.16 seconds = 8.23 MB/sec Timing buffered disk reads: 26 MB in 3.22 seconds = 8.07 MB/sec Timing buffered disk reads: 24 MB in 3.37 seconds = 7.12 MB/sec Timing buffered disk reads: 24 MB in 3.23 seconds = 7.42 MB/sec
When it was new last summer: Timing buffered disk reads: 770 MB in 3.00 seconds = 256.62 MB/sec
:~(
-- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E.R. composed on 2019-02-22 13:01 (UTC+0100):
Felix Miata wrote:
The question remaining is what next to do? .. systemctl status fstrim
# systemctl status fstrim â fstrim.service - Discard unused blocks Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) since Mon 2019-02-25 00:00:00 EST; 3 days ago Process: 25267 ExecStart=/usr/sbin/fstrim -av (code=exited, status=0/SUCCESS) Main PID: 25267 (code=exited, status=0/SUCCESS)
/usr/lib/systemd/system/fstrim.timer # 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 2019-02-22 02:42:04 EST; 6 days ago Docs: man:fstrim
grep -i "discard\|trim" /var/log/messages # grep -i "discard\|trim" /var/log/messages
grep: /var/log/messages: No such file or directory #
or
journalctl | grep -i "discard\|trim # journalctl | grep -i "discard\|trim" ... Aug 31 16:31:20 myhost nmbd[1465]: process_lanman_packet: Discarding datagram from IP 192.168.###.###. Source name myhost<00> is one of our names ! # journalctl | grep -i "discard\|trim" | wc -l 2954 # journalctl | grep -i "discard\|trim" | grep -v lanman #
Timing buffered disk reads: 28 MB in 3.27 seconds = 8.56 MB/sec Timing buffered disk reads: 24 MB in 3.19 seconds = 7.53 MB/sec Timing buffered disk reads: 26 MB in 3.16 seconds = 8.23 MB/sec Timing buffered disk reads: 26 MB in 3.22 seconds = 8.07 MB/sec Timing buffered disk reads: 24 MB in 3.37 seconds = 7.12 MB/sec Timing buffered disk reads: 24 MB in 3.23 seconds = 7.42 MB/sec
When it was new last summer: Timing buffered disk reads: 770 MB in 3.00 seconds = 256.62 MB/sec # hdparm -tT /dev/sda /dev/sdb /dev/sdc ... Timing buffered disk reads: 22 MB in 3.29 seconds = 6.68 MB/sec
:-( -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 28/02/2019 09.45, Felix Miata wrote:
Carlos E.R. composed on 2019-02-22 13:01 (UTC+0100):
Felix Miata wrote:
The question remaining is what next to do? .. systemctl status fstrim
# systemctl status fstrim â fstrim.service - Discard unused blocks Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) since Mon 2019-02-25 00:00:00 EST; 3 days ago Process: 25267 ExecStart=/usr/sbin/fstrim -av (code=exited, status=0/SUCCESS) Main PID: 25267 (code=exited, status=0/SUCCESS)
/usr/lib/systemd/system/fstrim.timer # 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 2019-02-22 02:42:04 EST; 6 days ago Docs: man:fstrim
This seems to be the same that I have
grep -i "discard\|trim" /var/log/messages # grep -i "discard\|trim" /var/log/messages
grep: /var/log/messages: No such file or directory #
or
journalctl | grep -i "discard\|trim # journalctl | grep -i "discard\|trim" ... Aug 31 16:31:20 myhost nmbd[1465]: process_lanman_packet: Discarding datagram from IP 192.168.###.###. Source name myhost<00> is one of our names ! # journalctl | grep -i "discard\|trim" | wc -l 2954 # journalctl | grep -i "discard\|trim" | grep -v lanman #
But the absence of entries in log is strange. I would try to run it manually and see: fstrim -av -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Carlos E. R. composed on 2019-02-28 12:07 (UTC+0100):
Felix Miata wrote:
Carlos E.R. composed on 2019-02-22 13:01 (UTC+0100):
Felix Miata wrote:
The question remaining is what next to do? .. systemctl status fstrim
# systemctl status fstrim â fstrim.service - Discard unused blocks Loaded: loaded (/usr/lib/systemd/system/fstrim.service; static; vendor preset: disabled) Active: inactive (dead) since Mon 2019-02-25 00:00:00 EST; 3 days ago Process: 25267 ExecStart=/usr/sbin/fstrim -av (code=exited, status=0/SUCCESS) Main PID: 25267 (code=exited, status=0/SUCCESS)
/usr/lib/systemd/system/fstrim.timer # 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 2019-02-22 02:42:04 EST; 6 days ago Docs: man:fstrim
This seems to be the same that I have
grep -i "discard\|trim" /var/log/messages # grep -i "discard\|trim" /var/log/messages
grep: /var/log/messages: No such file or directory #
or
journalctl | grep -i "discard\|trim # journalctl | grep -i "discard\|trim" ... Aug 31 16:31:20 myhost nmbd[1465]: process_lanman_packet: Discarding datagram from IP 192.168.###.###. Source name myhost<00> is one of our names ! # journalctl | grep -i "discard\|trim" | wc -l 2954 # journalctl | grep -i "discard\|trim" | grep -v lanman #
But the absence of entries in log is strange.
I would try to run it manually and see:
fstrim -av
# fstrim -av /disks/boot: 0 B (0 bytes) trimmed /: 0 B (0 bytes) trimmed I've emailed PNY, and ordered another brand. https://www.newegg.com/Product/Product.aspx?reviews=all&Item=N82E16820215167 I could slip this in as is right now https://www.newegg.com/Product/Product.aspx?Item=N82E16820156186 but its my only backup and it's over 6 months old. With the current as tenous as it is I hesitate to risk its current content by trying clone over it from the current. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 28/02/2019 13.25, Felix Miata wrote:
Carlos E. R. composed on 2019-02-28 12:07 (UTC+0100):
fstrim -av
# fstrim -av /disks/boot: 0 B (0 bytes) trimmed /: 0 B (0 bytes) trimmed
I tried on mine: Telcontar:~ # fstrim -av /other/ssd-test: 3.8 GiB (4092694528 bytes) trimmed /boot: 928.1 MiB (973135872 bytes) trimmed /: 99.1 GiB (106444374016 bytes) trimmed Telcontar:~ # As you see, my three partitions on that disk are trimmed - except swap (I don't know why). I'm surprised at the amount listed for /other/ssd-test, as I have not used that partition in months. Telcontar:~ # df -h /other/ssd-test /boot / Filesystem Size Used Avail Use% Mounted on /dev/sde3 15G 11G 3.8G 75% /other/ssd-test /dev/sde4 1011M 77M 883M 9% /boot /dev/sde5 148G 49G 92G 35% / Telcontar:~ # A second attemp reports: Telcontar:~ # fstrim -av /other/ssd-test: 0 B (0 bytes) trimmed /boot: 0 B (0 bytes) trimmed /: 313.8 MiB (328978432 bytes) trimmed Telcontar:~ # I suspect that in your case, trimming is disabled. You could try lsblk --discard in my case: Telcontar:~ # lsblk --discard /dev/sde NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sde 0 512B 2G 0 ├─sde1 0 512B 2G 0 ├─sde2 0 512B 2G 0 ├─sde3 0 512B 2G 0 ├─sde4 0 512B 2G 0 └─sde5 0 512B 2G 0 Telcontar:~ # Check your mount options. If you use LVM or encryption, things change, too. For example: Isengard:~ # fstrim -av /: 376 MiB (394194944 bytes) trimmed /home doesn't appear, it is encrypted. Isengard:~ # lsblk --discard /dev/sda NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO sda 0 512B 2G 0 ├─sda1 0 512B 2G 0 ├─sda2 0 512B 2G 0 ├─sda3 0 512B 2G 0 ├─sda4 0 512B 2G 0 └─sda5 0 512B 2G 0 └─cr_home 0 0B 0B 0 Isengard:~ # Which is because I forgot to add the option "allow_discards" to /etc/crypttab, and I did not reboot the machine since I did.
I've emailed PNY, and ordered another brand. https://www.newegg.com/Product/Product.aspx?reviews=all&Item=N82E16820215167
I could slip this in as is right now https://www.newegg.com/Product/Product.aspx?Item=N82E16820156186 but its my only backup and it's over 6 months old. With the current as tenous as it is I hesitate to risk its current content by trying clone over it from the current.
Yes, that's reasonable. But why is the current disk so slow I don't understand. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Thu, Feb 28, 2019 at 4:06 PM Carlos E. R. <robin.listas@telefonica.net> wrote: ...
I tried on mine:
Telcontar:~ # fstrim -av /other/ssd-test: 3.8 GiB (4092694528 bytes) trimmed /boot: 928.1 MiB (973135872 bytes) trimmed /: 99.1 GiB (106444374016 bytes) trimmed Telcontar:~ #
...
A second attemp reports:
Telcontar:~ # fstrim -av /other/ssd-test: 0 B (0 bytes) trimmed /boot: 0 B (0 bytes) trimmed /: 313.8 MiB (328978432 bytes) trimmed Telcontar:~ #
What is your filesystem type for all three? -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 28/02/2019 14.24, Andrei Borzenkov wrote:
On Thu, Feb 28, 2019 at 4:06 PM Carlos E. R. <robin.listas@telefonica.net> wrote: ...
I tried on mine:
Telcontar:~ # fstrim -av /other/ssd-test: 3.8 GiB (4092694528 bytes) trimmed /boot: 928.1 MiB (973135872 bytes) trimmed /: 99.1 GiB (106444374016 bytes) trimmed Telcontar:~ #
...
A second attemp reports:
Telcontar:~ # fstrim -av /other/ssd-test: 0 B (0 bytes) trimmed /boot: 0 B (0 bytes) trimmed /: 313.8 MiB (328978432 bytes) trimmed Telcontar:~ #
What is your filesystem type for all three?
Me? /other/ssd-test: ext4 /boot: ext2 / ext4 I find curious that the job was done Monday, yet today it claims "99.1 GiB trimmed" - I did run zypper up yesterday (and rebooted), but 100 gigs?: Telcontar:~ # grep -i "discard\|trim" /var/log/messages <3.6> 2019-02-25 00:00:18 Telcontar fstrim 10518 - - /boot: 932 MiB (977321984 bytes) trimmed <3.6> 2019-02-25 00:00:18 Telcontar fstrim 10518 - - /other/ssd-test: 3.8 GiB (4092694528 bytes) trimmed <3.6> 2019-02-25 00:00:18 Telcontar fstrim 10518 - - /: 99.4 GiB (106738315264 bytes) trimmed <3.6> 2019-02-25 00:00:18 Telcontar systemd 1 - - Started Discard unused blocks. <3.6> 2019-02-27 12:23:32 Telcontar systemd 1 - - Stopped Discard unused blocks once a week. <3.6> 2019-02-27 12:26:09 Telcontar systemd 1 - - Started Discard unused blocks once a week. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Thu, Feb 28, 2019 at 4:56 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 28/02/2019 14.24, Andrei Borzenkov wrote:
On Thu, Feb 28, 2019 at 4:06 PM Carlos E. R. <robin.listas@telefonica.net> wrote: ...
I tried on mine:
Telcontar:~ # fstrim -av /other/ssd-test: 3.8 GiB (4092694528 bytes) trimmed /boot: 928.1 MiB (973135872 bytes) trimmed /: 99.1 GiB (106444374016 bytes) trimmed Telcontar:~ #
...
A second attemp reports:
Telcontar:~ # fstrim -av /other/ssd-test: 0 B (0 bytes) trimmed /boot: 0 B (0 bytes) trimmed /: 313.8 MiB (328978432 bytes) trimmed Telcontar:~ #
What is your filesystem type for all three?
Me?
/other/ssd-test: ext4 /boot: ext2 / ext4
Indeed, ext4 "remembers" last trimmed size, at lest until reboot.
I find curious that the job was done Monday, yet today it claims "99.1 GiB trimmed" - I did run zypper up yesterday (and rebooted), but 100 gigs?:
fstrim has no knowledge about unmapped areas. It simply requests filesystem to trim unused space. Filesystem has no way to know whether unused area had been trimmed on storage device or not. So it will always issue the same request every time you call trim. And even driver for block storage does not normally know it - it simply forwards request to trim to device itself and device does not reply how much data it actually trimmed. ext4 in this case cheats - it saves last trim result and so avoids calling into block device if it looks like nothing has changed.
Telcontar:~ # grep -i "discard\|trim" /var/log/messages <3.6> 2019-02-25 00:00:18 Telcontar fstrim 10518 - - /boot: 932 MiB (977321984 bytes) trimmed <3.6> 2019-02-25 00:00:18 Telcontar fstrim 10518 - - /other/ssd-test: 3.8 GiB (4092694528 bytes) trimmed <3.6> 2019-02-25 00:00:18 Telcontar fstrim 10518 - - /: 99.4 GiB (106738315264 bytes) trimmed <3.6> 2019-02-25 00:00:18 Telcontar systemd 1 - - Started Discard unused blocks. <3.6> 2019-02-27 12:23:32 Telcontar systemd 1 - - Stopped Discard unused blocks once a week. <3.6> 2019-02-27 12:26:09 Telcontar systemd 1 - - Started Discard unused blocks once a week.
-- Cheers / Saludos,
Carlos E. R. (from 15.0 x86_64 at Telcontar)
-- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
Carlos E. R. composed on 2019-02-28 14:06 (UTC+0100):
I suspect that in your case, trimming is disabled.
It turns out I had set discard as a filesystem option when formatting all EXT4 filesystems on the PNY SSD. So, continuous trim was on, as well as the fstrim.timer engaged, since 30 January. As yet I've found nothing about the ramifications of trying to use both at the same time. To recap, the 120G PNY SSD gave: when new: # hdparm -t /dev/sda: Timing buffered disk reads: 770 MB in 3.00 seconds = 256.62 MB/sec of late: # hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 22 MB in 3.10 seconds = 7.09 MB/sec I've replaced the PNY with this XPG 128G SSD: https://www.newegg.com/Product/Product.aspx?reviews=all&Item=N82E16820215167 I forgot to save hdparm -t output of the XPG before putting it into boot service. I do remember running it at the time with both 42.3 and TW and getting 528.## with both. Now that it's been in use 3 days, it's already down: hdparm -t /dev/sda /dev/sda: Timing buffered disk reads: 1524 MB in 3.00 seconds = 507.78 MB/sec But, only just 2 hours ago I turned off discard as a mount option, and haven't yet rebooted. The fstrim timer isn't due until tonight, so I guess I'll be rebooting some time before then. I emailed PNY about the 97% throughput loss according to its own RMA instructions provided by multiple locations over 72 hours ago, and filled out its technical support web form for same at the same time; no response to either as yet. :-( -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 2/28/19 2:06 PM, Carlos E. R. wrote:
Check your mount options. If you use LVM or encryption, things change, too.
For example:
Isengard:~ # fstrim -av /: 376 MiB (394194944 bytes) trimmed
/home doesn't appear, it is encrypted.
Thanks for that, turns out the trimming wasn't working for my encrypted partitions under LVM when I decided to check it.
Which is because I forgot to add the option "allow_discards" to /etc/crypttab, and I did not reboot the machine since I did.
In case of Tumbleweed man crypttab says there is a 'discard' option and no 'allow_discards' option. For LVM it's also issue_discards = 1 in /etc/lvm/lvm.conf -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
On 10/03/2019 12.49, Oleksii Vilchanskyi wrote:
On 2/28/19 2:06 PM, Carlos E. R. wrote:
Check your mount options. If you use LVM or encryption, things change, too.
For example:
Isengard:~ # fstrim -av /: 376 MiB (394194944 bytes) trimmed
/home doesn't appear, it is encrypted.
Thanks for that, turns out the trimming wasn't working for my encrypted partitions under LVM when I decided to check it.
Which is because I forgot to add the option "allow_discards" to /etc/crypttab, and I did not reboot the machine since I did.
discard is still not working on my home. I changed /etc/crypttab on the 28/2 and rebooted six days ago:
cr_home /dev/disk/by-id/ata-KINGSTON_...-part5 none timeout=300,allow_discards
But the log says: <3.4> 2019-03-04T00:21:10.823356+01:00 Isengard systemd-cryptsetup 596 - - Encountered unknown /etc/crypttab option 'allow_discards', ignoring. Looking on man, it says: discard Allow discard requests to be passed through the encrypted block device. This improves performance on SSD storage but has security implications. So, wrong syntax. Changing again, and scheduling another reboot. Googling, I see that "--allow-discards" is an option for "cryptsetup" command. Some posts mention that "allow_discards" exist somewhere in the documentation. The confusion could come from commands like "dmsetup table --showkeys" that show "allow_discards" if enabled. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Felix Miata composed on 2019-02-28 03:45 (UTC-0500):
Timing buffered disk reads: 24 MB in 3.23 seconds = 7.42 MB/sec
When it was new last summer: Timing buffered disk reads: 770 MB in 3.00 seconds = 256.62 MB/sec # hdparm -tT /dev/sda /dev/sdb /dev/sdc ... Timing buffered disk reads: 22 MB in 3.29 seconds = 6.68 MB/sec
I booted my Crucial backup SSD long enough to run hdparm. Its buffered disk reads are more than twice as fast as the failing PNY was when new, 540+ MB/sec in 42.3, 15.0 & TW. I'm back using the old slug for now. Waiting a few days to clone from it seems likely easier than trying to find out what software was installed on it since the backup was made. Replacement XPG http://www.newegg.com/Product/Product.aspx?Item=N82E16820215167 is supposedly en route. -- Evolution as taught in public schools is religion, not science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
participants (5)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E.R. -
Felix Miata -
Oleksii Vilchanskyi