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
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
-- https://unix.stackexchange.com/question ... d-for-trimIf 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.
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
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
The external device supports the "UNMAP" command though:
Code: Select all
sg_vpd -a /dev/sda
Code: Select all
cat /sys/block/sda/device/scsi_disk/*/provisioning_mode
full
Code: Select all
echo "unmap" >/sys/block/sda/device/scsi_disk/*/provisioning_mode
Code: Select all
fstrim -v /mnt/sda3
/mnt/sda3: 27.4 GiB (29447401472 bytes) trimmed
Code: Select all
fstrim -v /mnt/sda4
fstrim: /mnt/sda4: the discard operation is not supported