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)

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)

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 28/02/2019 14.24, Andrei Borzenkov wrote:

On Thu, Feb 28, 2019 at 4:06 PM Carlos E. R. 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)

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 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)