PATA-SSD: To TRIM or not to TRIM?

cameo · 2017-05-17 18:00:28

I lately acquired a Solid State Drive for IDE (a.k.a. PATA SSD) to revive an i686 box. Yet it's blank, and before putting it in there to install all the stuffs, I've attached it as slave /dev/sdb in another machine to prepare and format it. (The plan is to use disk encryption and btrfs at least for $HOME).

Here’s an impression of the disk, Transcend TS128GPSD330: link. There seems to be no online manual. The problem now is, I just can't surely determine whether the drive supports TRIM or not (the paper one does not mention it). And since it's made in 2016 I hope it does.

That's the specs so far:

# hdparm -I /dev/sdb | grep -i trim  # checking the PATA-SSD
#  # empty! :P
# lsblk -D
NAME            DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
fd0                    0        0B       0B         0
sda                    0        0B       0B         0
├─sda1                 0        0B       0B         0
└─sda2                 0        0B       0B         0
sdb                    0        0B       0B         0
sr0                    0        0B       0B         0

The Arch wiki says, "Non-zero values indicate TRIM support." it seems here's also none, though literally "0B" is not "0" – but "0B" is shown for every drive.

Despite that, the linked WP section states that PATA could support TRIM as well.

Well, I have to admit, that this is my very first SSD, and also no clue about that matter. All I could do has been to find some basic useful info. – So in the Arch wiki can I trigger TRIM "manually" by modifying fstab? Or occasionally run fstrim (if this works at all)?

Anyway, if the disk absolutely is not capable of TRIM, what can I do? Are there any alternative tools for "garbage collection"? Or am I doomed just wearing out the disk for about 1–2 years while it's getting slower and slower until I throw it away?

Ropid · 2017-05-17 21:24:34

Both fstrim and the discard mount option need the TRIM command to work.

The way I remember, the TRIM command was only available with AHCI. When SSDs were used in IDE mode, you couldn't do the normal TRIM. You would have special software by the manufacturer that could do a similar job as what "fstrim" does, meaning something you would schedule to run periodically. That type of software was something for Windows XP and such. I don't know if any manufacturer had Linux versions. This is of course all about SATA drives. I didn't know PATA SSDs existed.

I would assume that the manufacturer keeps this in mind if the facts are that TRIM really can't work. They could add a lot of extra, hidden space to the drive to make it so it can keep its performance up even if it's 100% full.

If you are worried, what you could do is keep a certain amount of the drive unallocated and outside of partitions, for example 25% of its size. If there's no method to do a "secure erase" of the drive, you would have to be careful to never write anything into that area you decide to reserve. The moment something gets written in there, the SSD controller will forever think it's in use as only TRIM or a secure erase can reverse that.

In that "lsblk -D" output, I see 512B and 2G on my SSDs in those two columns that were mentioned, and I see 0B for my HDD, so that "0B" probably doesn't count as literally different from "0".

Last edited by Ropid (2017-05-17 21:25:49)

frostschutz · 2017-05-17 23:22:25

cameo wrote:

Anyway, if the disk absolutely is not capable of TRIM, what can I do?

trim is overrated - just use it and be happy

I've attached it as slave /dev/sdb in another machine to prepare and format it.

If possible, don't make it share with another device.

Last edited by frostschutz (2017-05-17 23:26:49)

cameo · 2017-05-18 19:37:30

Thanks for the responses, appreciated.
Well, too bad there seems not to be even 'virtual TRIMing' <- lolz~

frostschutz wrote:

If possible, don't make it share with another device.

You mean as part of a raid? No, the drive will be master and the only one in a laptop anyway.

Ropid wrote:

I would assume that the manufacturer keeps this in mind if the facts are that TRIM really can't work. They could add a lot of extra, hidden space to the drive to make it so it can keep its performance up even if it's 100% full.

So far I could't find any extras.

Ropid wrote:

If you are worried, what you could do is keep a certain amount of the drive unallocated and outside of partitions, for example 25% of its size. If there's no method to do a "secure erase" of the drive, you would have to be careful to never write anything into that area you decide to reserve.

Hm, I'm willing to sacrifice e.g. 28GB and leave 100GB if that helps ...
Then that free space will be used for what, for 'SSD internal use' for performance? Or for "emergency disk space" when the other has gone?

Then you guys could tell about dos and don'ts using an SSD without TRIM. Is there a way to measure the degradations of disk speed and the 'sectors' (you know what I mean)?

So what filesystem(s) are the best for this case, these with journaling or without? Can I still use a swap partiton and disk encryption? And what about defragmentation (btrfs)?

Last edited by cameo (2017-05-19 18:21:44)

Ropid · 2017-05-18 20:30:40

You don't have to worry at all about doing something special about journaling or whatnot. You really can use the drive like a normal drive.

About what those 28G unused would do to help the SSD controller, this has to do with how the SSD works internally. The NAND memory chips can only be freely written to when they are "empty". After they were once written to, the contents cannot be freely overwritten. You have to wipe large parts of the memory to get it back into its empty state, can then again write new stuff into it. What this means is, to really, physically overwrite the data in a small spot somewhere, you would have to wipe and rewrite a large block surrounding that small spot. Because of this limitation, when the PC wants to overwrite something, the SSD controller will instead create a new version of that overwritten spot in an empty part of the NAND memory. That's what it uses empty space for. Before the empty space runs out, it does some sort of defragmentation to get empty space back. Those 28G left unused would mean that work doesn't have to be done as often.

That 128G disk you see from the outside is a fake disk that the SSD controller presents to the PC. Internally that "disk" looks different, and where exactly a sector is saved inside the memory chips changes whenever you write something, and changes when the SSD controller does its internal reorganization work. The SSDs always have some unused reserve area inside. It can't work without having some empty memory available at all times, so it needs that reserve area to allow you to use 100% of that 128G disk it advertises. I don't know if manufacturers document how large that unused area is in different drives. If it's something small like 3% hidden extra space, leaving a part of the 128G unused would be a good idea, but if the manufacturer was generous enough you wouldn't need to worry.

There's also the thing that PATA is slower than SATA3. It might be completely impossible to ever notice a slow-down, no matter what you do to the drive.

Last edited by Ropid (2017-05-18 20:33:52)

cameo · 2017-05-27 13:52:57

Now I've partioned the drive, and besides swap, formatted the partitions: /boot will be btrfs, / and /home f2fs; IMO no LVM or disc-encryption suffices. And I read much about aligning the (GPT) partitions beginning at 4 kB sectors, or 1 MiB, respectively. Further, about 15 GiB of the drive is left blank for better performance.

Actually I'm doing formatting with the fs-specific tools, rather than with (g)parted and such. Anyway, I'm now wondering about the mkfs status messages, since the PATA-SSD can't do TRIM – which is "enabled" now~ That's the output:

# mkfs.f2fs -l HOME /dev/sdb4

	F2FS-tools: mkfs.f2fs Ver: 1.8.0 (2017-02-03)

Info: Debug level = 0
Info: Label = HOME
Info: Trim is enabled
Info: [/dev/sdb4] Disk Model: TS128GPSD330    0511
Info: Segments per section = 1
Info: Sections per zone = 1
Info: sector size = 512
Info: total sectors = 167772160 (81920 MB)
Info: zone aligned segment0 blkaddr: 256
Info: format version with
  "Linux version 4.11.2-1-ARCH (builduser@tobias) (gcc version 7.1.1 20170516 (GCC) ) #1 SMP PREEMPT Mon May 22 07:14:03 CEST 2017"
Info: [/dev/sdb4] Discarding device
Info: This device doesn't support BLKSECDISCARD
Info: This device doesn't support BLKDISCARD
Info: Overprovision ratio = 0.700%
Info: Overprovision segments = 576 (GC reserved = 293)
Info: format successful

# hdparm -I /dev/sdb | grep -i trim

(That for the root-partition reads accordingly.)

To me it seems 4 kB aligning worked. But must I worry about these lines?

Info: Trim is enabled
Info: [/dev/sdb4] Discarding device
Info: This device doesn't support BLKSECDISCARD
Info: This device doesn't support BLKDISCARD

As hdparm confirms, there's still no TRIM (what would be fine). So must I switch it off, and if yes, how? And what's about that "discarding" stuff? Having read this I guess, without TRIM support there's none of it anyway, despite this partiton is called "Discarding device" nonetheless. Probably for avoiding any trouble here, it suffices to put an "nodiscard" option later in fstab, right?

Next, what is also a bit strange, after formatting (both gparted or mkfs.f2fs), though of course f2fs-tools was installed, in parted these partitions appear as not formatted ...

# parted /dev/sdb
(parted) unit mib                                                         
(parted) print                                                            
Modell: ATA TS128GPSD330 (scsi)
Festplatte  /dev/sdb:  122105MiB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang    Ende       Größe     Dateisystem     Name  Flags
 1      1,00MiB   257MiB     256MiB    btrfs           BOOT  boot, esp
 2      257MiB    3329MiB    3072MiB   linux-swap(v1)  SWAP
 3      3329MiB   23809MiB   20480MiB
 4      23809MiB  105729MiB  81920MiB

... and in gparted come with errors, stating f2fs-tools would be missing.

Last edited by cameo (2017-05-27 17:12:27)

Arch Linux

#1 2017-05-17 18:00:28

PATA-SSD: To TRIM or not to TRIM?

#2 2017-05-17 21:24:34

Re: PATA-SSD: To TRIM or not to TRIM?

#3 2017-05-17 23:22:25

Re: PATA-SSD: To TRIM or not to TRIM?

#4 2017-05-18 19:37:30

Re: PATA-SSD: To TRIM or not to TRIM?

#5 2017-05-18 20:30:40

Re: PATA-SSD: To TRIM or not to TRIM?

#6 2017-05-27 13:52:57

Re: PATA-SSD: To TRIM or not to TRIM?

Board footer