Possible SSD [ Kubuntu drive ] issue.

[raffytaffy]

Normally on dmesg I would get the *null* then remount message, but now I get this

[    2.159562] scsi 1:0:0:0: Direct-Access     ATA      M4-CT256M4SSD2   070H PQ: 0 ANSI: 5
[    2.159818] sd 1:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)
[    2.159863] sd 1:0:0:0: Attached scsi generic sg1 type 0
[    2.159922] sd 1:0:0:0: [sda] Write Protect is off
[    2.159924] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.159959] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.160515]  sda: sda1
[    2.160958] ata6.00: configured for UDMA/133
[    2.160979] sd 1:0:0:0: [sda] Attached SCSI disk

It is attached to the SATA port on the mobo that the booklet said to attach the main drive to. Is this a problem?

I run sudo fstrim -v / on it and it shows me this

root@ralph-desktop:~# sudo fstrim -v /
/: 246782640128 bytes were trimmed
root@ralph-desktop:~# sudo fstrim -v /
/: 216203264 bytes were trimmed
root@ralph-desktop:~# sudo fstrim -v /
/: 0 bytes were trimmed

I have a trim.log in /var/log and this morning I was only able to trim once which was actually logged, the others, nothing, as if it did not happen. I ran a quick benchmark on it, results

root@ralph-desktop:~# hdparm -Tt /dev/sda

/dev/sda:
Timing cached reads: 9622 MB in 1.99 seconds = 4824.32 MB/sec
Timing buffered disk reads: 1348 MB in 3.00 seconds = 449.26 MB/sec

SSD - Crucial m4 256gb and I know, too much trimming is bad, but I would like to set up something once a week perhaps or so, but it seems I can't even do that as the log simply does not log the trim cron job I set as a test. Using thes commands:

sudo (gksu is hidding somewhere) gedit /etc/cron.daily/trim

#!/bin/sh
LOG=/var/log/trim.log
echo "*** $(date -R) ***" >> $LOG
fstrim -v / >> $LOG
fstrim -v /home >> $LOG

It worked once on auto, shortly after I set it, but then daily I check the log and nada. I ran it manually this morning, first run, nothing in the log, second run it logged it, 2 seconds after. First run it said it trimmed entire SSD but second run only trimmed maybe 80gbs?

I should mention I am getting very slow transfer speed on SATAIII HHDs about 60~80/s meanwhile on Win it WAS AROUND 100-110/s, I am sure this is a pebkac issue but I ran [QUOTE]sudo rm /var/lib/ureadahead/pack[QUOTE] as instructed in one of the ubuntu articles to see if I can rectify the issue, but no grapes.

[raffytaffy]

I also do not understand what it is trimming when this is all I have on the drive



Yet it claims to have trimmed the entire drive, second run, about 80gbs, 3rd run 0. Very confusing this is.

[millusions]

add discard to fstab, ONLY if hard disk supports trim

my / looks like this:
UUID=1d1f4e5e-80bc-43b1-9eff-74a51a18d8d2 / ext4 errors=remount-ro,noatime,discard 0 1

[raffytaffy]

Don't think it took dmesg spat this out - EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) In fact all my HDDs mount like that :/

Getting somewhere I got this, this time around, noatime not showing

EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)
[ 4.974382] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 5.005767] systemd-udevd[417]: starting version 204
[ 5.067093] lp: driver loaded but no devices found
[ 5.073474] it87: Found IT8721F chip at 0x290, revision 1
[ 5.079852] ppdev: user-space parallel port driver
[ 5.140005] EXT4-fs (sda1): re-mounted. Opts: discard,errors=remount-ro

[SteveRiley]

Normally on dmesg I would get the *null* then remount message, but now I get this
...
It is attached to the SATA port on the mobo that the booklet said to attach the main drive to. Is this a problem?

Looks fine; mine is nearly the same. The only difference is the model number of the drive.

I run sudo fstrim -v / on it and it shows me this

fstrim does one thing: it calls the kernel's FITRIM ioctl. This, in turn, send a command to the file system. The file system does all the actual work. Different file systems take different approaches. From what I've read, EXT4 tries to avoid trimming the same areas that it trimmed previously if those areas have seen no activity. If you check the man page for fstrim, you'll see that the --verbose option is reporting only the potential number of discarded bytes, not the actual. Different file systems probably have different ways of reporting this number. On my machine, which has one BTRFS file system with two subvolumes, fstrim reports the same approximate number every time I run it. Furthermore, the number seems to have absolutely no relationship to anything else -- used space, free space, anything.

I have a trim.log in /var/log and this morning I was only able to trim once which was actually logged, the others, nothing, as if it did not happen.

Our forum member Oshunluvr has written here about using cron jobs for fstrim. I'd recommend searching the forum for his posts about the topic.

sudo (gksu is hidding somewhere) gedit

Kubuntu is KDE -- there is no gksu. The equivalent command is kdesudo. And the default GUI text editor is Kate, which integrates much better with the rest of KDE than Gedit from GNOME.

[SteveRiley]

add discard to fstab, ONLY if hard disk supports trim

Search the forum here -- you'll find a lot of discussion about this. The general consensus is that using discard isn't a good idea. It can greatly slow down deletes and file updates, because the operation is non-queued. Periodically running fstrim has become the generally accepted practice. More information: https://patrick-nagel.net/blog/archives/337