SSD TRIM

[rych]

I'm checking whether the TRIM command is supported on the current Porteus for both my system SSD (NTFS) and through the USB enclosed SSD (ext4+NTFS) Booting from NVMe USB enclosure

Those (majority of you) who use ordinary USB drives need not worry about this, see https://superuser.com/questions/1172983 ... -supported

Those who don't access the host SSD (likely with Windows NTFS) while in Porteus also shouldn't worry about this.

When booting into Windows TRIM is normally taken care of. To check the support of TRIM under Windows go to Disk Defrag or Analysis or something in Control Panel or something and see if the button "Optimize" is available, and when it was done last automatically. For SSD that implies TRIM and not defragmentation. Indeed defragmenation of SSD disk shouldn't even be done, see for example Fragmentation of modules on NTFS hard drive (Post by Rava #96283)

Under Windows one can see whether TRIM actually works by running the CLI program trimcheck-0.7-win64.exe on a given partition. I've confirmed it on my USB enclosed SSD to check the NTFS partition at least, as Windows doesn't see the ext4 partition. But it was enough to establish that my USB drive indeed successfully passes through the TRIM command to the enclosed SSD. Now let's see if Linux and Porteus support it at this stage.

I'll be following the steps in https://wiki.archlinux.org/title/Solid_ ... IM_support

((The last post about TRIM on Porteus was more than 4 years ago: Как включить трим для ssd на porteus? ))

By default TRIM is not supported on any disks according to:

Code: Select all

lsblk --discard

(For SATA SSDs only, not NVMe SSDs we could check also using:

Code: Select all

hdparm -I /dev/sda | grep TRIM
hdparm -I /dev/sdb | grep TRIM
hdparm -I /dev/nvme0n1 | grep TRIM

)

We note that none of the partitions are mounted with discard option as seen by either

Code: Select all

cat /etc/fstab
cat /proc/mounts

However, that's perhaps not the main problem:

If the filesystem is mounted with discard, then deleting files will automatically cause the TRIM command to be issued. This often has a negative performance impact, so it's generally better not to use that mount option and to instead run fstrim periodically, which will work as long as all the block device layers support it (for example, if you're using LUKS for encryption, you'll need to use cryptsetup --allow-discards). Unless you use this mount option, the TRIM command will not be automatically sent by the filesystem driver when you unlink files.

-- https://unix.stackexchange.com/question ... d-for-trim

The problem is clear from:

Code: Select all

root@porteus:/W# fstrim -v /mnt/sda3
fstrim: /mnt/sda3: the discard operation is not supported
root@porteus:/W# fstrim -v /mnt/sda4
fstrim: /mnt/sda4: the discard operation is not supported
root@porteus:/W# fstrim -v /mnt/nvme0n1p3
fstrim: /mnt/nvme0n1p3: the discard operation is not supported

Again I suspect that it's not the missing mount "discard" option which is the problem (we could tune2fs -o discard /dev/sda4, remount and check -- that won't make a difference?).

Let's keep digging through the layers.

The LBPME bit is not set on both drives accoriding to

Code: Select all

sg_readcap -l /dev/sda
sg_readcap -l /dev/nvme0n1

So the kernel assumes the devicess do not support it...

The external device supports the "UNMAP" command though:

Code: Select all

sg_vpd -a /dev/sda

However,

Code: Select all

cat /sys/block/sda/device/scsi_disk/*/provisioning_mode
full

Let's try to change that:

Code: Select all

echo "unmap" >/sys/block/sda/device/scsi_disk/*/provisioning_mode

Now this works on ext4 partition:

Code: Select all

fstrim -v /mnt/sda3
/mnt/sda3: 27.4 GiB (29447401472 bytes) trimmed

However, the NTFS partition on the same device still can't be TRIM'med for some reason:

Code: Select all

fstrim -v /mnt/sda4
fstrim: /mnt/sda4: the discard operation is not supported

Why not? But perhaps, it's better to be left to Windows to TRIM NTFS. Indeed the only reason to have an NTFS partition on my USB SSD disk was for interoperability with Windows. So when plugged into Windows, let Windows hopefully (or manually by finding that Optimize disk button) run TRIM there.

[Ed_P]

Indeed the only reason to have an NTFS partition on my USB SSD disk was for interoperability with Windows.

Rather than a journaling format why don't you use exFat?

[rych]

why don't you use exFat

Undecided, but from a recent search I had am impression that exfat would be easier to lose files in case of a system crash or a USB hot unplugging -- and that still happens to me sometimes. NTFS feels more advanced, more like a first-class citizen for both static disks and removable media both on Windows, which will always recover files, and on Linux with two its 2 mature drivers ntfs-3g and ntfs3 along with utils for checking and recovery, whereas exfat is only recently contributed to kernel by Samsung I think. There was something funny about cluster size too: it's a bit wasteful with exfat, no? Also, GParted although supports exfat, can't resize it for example. Things like that. Besides I just want to keep a focus on NTFS for now. Some journaling is good.

Could you tell me how I'm wrong and why you chose exfat over NTFS? Was it a faster speed under Linux? Did you do any benchmarks? How long ago? Did you use teh new kernle drivers for exfat and ntfs3?

I suspect that these choices need fresh research and retesting every coupe of years because of their (constant) development, progress and maturity.

[Ed_P]

why you chose exfat over NTFS?

Less writes to the USB drive, less overhead, less wear on the drive, would imply faster access of files on the drive imo. I never tested timings though.

[nanZor]

I'm interested in this myself, as I run Porteus on a lot of "hockey puck" sized hardware, with cheap ssd's inside, and other Linux OS permanently installed on them.

So I boot Porteus from USB and have my fun that way. On the other ssd-installed OS, I usually see the "discard" option when it detected and set up for an ssd. And of course 10-year old advice too.

Personally, I'm not trying to make these cheap internal ssd's last for 20 years, so an fstrim-like command issued every blue moon might be nice if I were to do a "frugal" Porteus install on one of the ssd's. I'll look into that for Porteus and see what I can come up with.

UPDATE:
With all the varying advice, and since Porteus is designed to run portably from a USB stick with no trim needed, perhaps this might be a good option to boot from and run your trim once in awhile from the terminal:

GPARTED LIVE:
https://sourceforge.net/projects/gparte ... ve-stable/

Use the ZIP file, and not the iso, and you can install Gparted Live to a usb stick the same way you install Porteus - that is copy the files, and run the bootloader installer *if necessary*. Should be familiar to us Porteus users. It should have all the fstrim and even systemd commands available to do a trim on the target device if you boot from it once a week/month or so. Or perhaps if one is doing distro-hopping installs.

My .02c for a blue-moon solution...