Jump to content

Recommended Posts

Posted

My setup is SD boot and rootfs on ssd on USB 2.0

 

smartctl on laptop reports TIRM is enabled, but it is missing on orange pi PC. using the same SSD in the same USB box. 

 

Do I need another ssd, USB box, or armbian upgrade for TRIM support?

root@focal-armv7l ~ $ fstrim -v /
fstrim: /: the discard operation is not supported

root@focal-armv7l ~ $ mount | grep " / "
/dev/sda1 on / type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro,commit=600)

root@focal-armv7l ~ $ smartctl -i -d sat /dev/sda
smartctl 7.1 2019-12-30 r5022 [armv7l-linux-5.9.14-sunxi] (local build)
Copyright (C) 2002-19, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Device Model:     SSD 128GB
Serial Number:    GS20231128661058
LU WWN Device Id: 0 000000 000000000
Firmware Version: HT3618C8
User Capacity:    128,035,676,160 bytes [128 GB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    Solid State Device
Form Factor:      2.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-4 T13/BSR INCITS 529 revision 5
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 1.5 Gb/s)
Local Time is:    Wed Feb  7 06:02:15 2024 EET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

# Missing TRIM support


 

lsblk -D also reports zeros for discard 
 

root@focal-armv7l ~ $ lsblk -D
NAME        DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                0        0B       0B         0
├─sda1             0        0B       0B         0
└─sda2             0        0B       0B         0
mmcblk0            0        4M     3.5G         0
├─mmcblk0p1        0        4M     3.5G         0
└─mmcblk0p2        0        4M     3.5G         0
zram0              0        4K       2T         0
zram1              0        4K       2T         0

 

I'm using previous armbian ver. Can an upgrade help to solve the missing trim issue?
 

root@focal-armv7l ~ $ cat /etc/*release
# PLEASE DO NOT EDIT THIS FILE
BOARD=orangepipc
BOARD_NAME="Orange Pi PC"
BOARDFAMILY=sun8i
BUILD_REPOSITORY_URL=https://github.com/armbian/build
BUILD_REPOSITORY_COMMIT=b9814056
DISTRIBUTION_CODENAME=focal
DISTRIBUTION_STATUS=supported
VERSION=20.11.3
LINUXFAMILY=sunxi
BRANCH=current
ARCH=arm
IMAGE_TYPE=stable
BOARD_TYPE=conf
INITRD_ARCH=arm
KERNEL_IMAGE_TYPE=Image
IMAGE_UUID=3d974917-e04a-4ec3-bc8a-cc3d2427eb76
# PLEASE DO NOT EDIT THIS FILE
BOARD=orangepipc
BOARD_NAME="Orange Pi PC"
BOARDFAMILY=sun8i
BUILD_REPOSITORY_URL=git@github.com:armbian/build.git
BUILD_REPOSITORY_COMMIT=e846ef656-dirty
DISTRIBUTION_CODENAME=focal
DISTRIBUTION_STATUS=supported
VERSION=21.02.3
LINUXFAMILY=sunxi
BRANCH=current
ARCH=arm
IMAGE_TYPE=stable
BOARD_TYPE=conf
INITRD_ARCH=arm
KERNEL_IMAGE_TYPE=Image
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.6 LTS"
NAME="Ubuntu"
VERSION="20.04.6 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.6 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

 

P.S. ix.io is taking a break

 

 

Posted
Quote

Yep, for instance I have a 2TB hard drive in mine that costs like 70ish bucks, a 2TB ssd depending on brand is at least 300 bucks. If you have the money sure go for an SSD it's going to be better and faster I have 500GB ssds in my laptop and desktop and they are so good I'll never use a hard drive in my PCs for the boot drive again, but to get a nice sized SSD that will fit most of my games they're too much money yet.


Nice. What about missing trim on SSD over USB 2.0?

Posted
On 2/8/2024 at 11:35 PM, Gunjan Gupta said:

I believe yours is more of a generic Linux related question than something that is specific to Armbian

It is hardware and its support by armbian question.

On the latest armbian smartctl reports Trim is supported, but fstrim still not work (the discard operation is not supported)

 

On 2/8/2024 at 11:35 PM, Gunjan Gupta said:

ave you gone through Arch Linux's Solid State Drive page

Sure. can't you see Trim is enabled by smartctl and discard mount option is on?

Posted
08.02.2024 в 08:19, Crossplatform Vlad сказал:

What about missing trim on SSD over USB 2.0?

This is a common Linux issue and we usually do not provide assistance.

 

But you have interested me in this fact.

If I understood correctly, then the same SSD drive connected via the SATA connector - trim mode is possible,

and connected via a USB-SATA adapter - trim mode is impossible?

Publish the DMESG output of the line where the USB-SATA adapter is defined.

 

I have a lot of these things. I'll check it out.

Posted
07.02.2024 в 07:21, Crossplatform Vlad сказал:

smartctl on laptop reports TIRM is enabled, but it is missing on orange pi PC. using the same SSD in the same USB box. 

 

07.02.2024 в 07:21, Crossplatform Vlad сказал:
DISTRIBUTION_CODENAME=focal

 

07.02.2024 в 07:21, Crossplatform Vlad сказал:
root@focal-armv7l ~ $ smartctl -i -d sat /dev/sda
smartctl 7.1 2019-12-30 r5022 [armv7l-linux-5.9.14-sunxi] (local build)

uname -r ?

Have you updated the kernel on this distribution?

 

@Crossplatform Vlad My recommendations:

Make a new installation of the distribution based on ubuntu 22.04.
The build system works on this version.
Why is that? Do you need further explanations?

Posted
13 hours ago, going said:

If I understood correctly, then the same SSD drive connected via the SATA connector - trim mode is possible,

and connected via a USB-SATA adapter - trim mode is impossible?

Not exactly. trim and fstrim works well on the same SSD connected to USB 3.* on laptop using the same USB-SATA adapter. I didn't connect SSD to a sata connecor directly. 

But trim is missing on USB 2.0 only orange pi pc. 
 

 

13 hours ago, going said:

Publish the DMESG output of the line where the USB-SATA adapter is defined.

here it is (Realtek RTL9201). sda1 is root fs as btrfs, sda2 is swap. Previously I created SSD root fs as ext4 and the result was the same (discard is not supported)
The full dmesg is also attached. 

[    2.645774] usb 4-1: new high-speed USB device number 2 using ehci-platform
[    2.812076] usb 4-1: New USB device found, idVendor=0bda, idProduct=9201, bcdDevice=f2.00
[    2.812110] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.812123] usb 4-1: Product: RTL9201
[    2.812133] usb 4-1: Manufacturer: Realtek
[    2.812144] usb 4-1: SerialNumber: 012345678999
[    2.836676] usb-storage 4-1:1.0: USB Mass Storage device detected
[    2.838158] scsi host0: usb-storage 4-1:1.0
[    2.845086] usbcore: registered new interface driver uas


[    4.309250] scsi 0:0:0:0: Direct-Access     SSD 128G B                1.02 PQ: 0 ANSI: 6
[    4.310067] sd 0:0:0:0: Attached scsi generic sg0 type 0
[    4.313065] sd 0:0:0:0: [sda] 250069680 512-byte logical blocks: (128 GB/119 GiB)
[    4.314870] sd 0:0:0:0: [sda] Write Protect is off
[    4.314891] sd 0:0:0:0: [sda] Mode Sense: 37 00 00 08
[    4.316343] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[    4.331219]  sda: sda1 sda2
[    4.331965] sd 0:0:0:0: [sda] Attached SCSI disk
[    4.527111] BTRFS: device fsid df0ead50-f772-46c2-9e27-c76368fe0a04 devid 1 transid 502 /dev/sda1 scanned by systemd-udevd (189)
[    4.755889] BTRFS info (device sda1): using crc32c (crc32c-generic) checksum algorithm
[    4.755972] BTRFS info (device sda1): using free space tree
[    4.791422] BTRFS info (device sda1): start tree-log replay

 

 

13 hours ago, going said:

I have a lot of these things. I'll check it out.

do you have a many years old orange pi pc? or USB 2.0 only board?

dmesg on orange pi pc with usb-sata SSD.txt

Posted (edited)
9 minutes ago, going said:

Have you updated the kernel on this distribution?

 

@Crossplatform Vlad My recommendations:

Make a new installation of the distribution based on ubuntu 22.04.
The build system works on this version.
Why is that? Do you need further explanations?

Yes. on the latest armbian with ubuntu 22.04 the result is the same. dmesg logs above are grabbed on the latest armbian with ubuntu 22.04 

the fresh armbian installation:
 

root@jammy-armv7l ~ $ uname -r
6.1.63-current-sunxi
root@jammy-armv7l ~ $ uname -a
Linux jammy-armv7l 6.1.63-current-sunxi #1 SMP Mon Nov 20 10:52:19 UTC 2023 armv7l armv7l armv7l GNU/Linux
root@jammy-armv7l ~ $ cat /etc/*release
# PLEASE DO NOT EDIT THIS FILE
BOARD=orangepipc
BOARD_NAME="Orange Pi PC"
BOARDFAMILY=sun8i
BUILD_REPOSITORY_URL=https://github.com/armbian/build
BUILD_REPOSITORY_COMMIT=b600ead20
LINUXFAMILY=sunxi
ARCH=arm
IMAGE_TYPE=nightly
BOARD_TYPE=csc
INITRD_ARCH=arm
KERNEL_IMAGE_TYPE=zImage
FORCE_BOOTSCRIPT_UPDATE=
FORCE_UBOOT_UPDATE=
VENDOR="Armbian_community"
VENDORDOCS="https://docs.armbian.com"
VENDORURL="https://github.com/armbian/build"
VENDORSUPPORT="https://community.armbian.com/"
VENDORBUGS="https://github.com/armbian/community/issues"
BOOTSCRIPT_FORCE_UPDATE="no"
BOOTSCRIPT_DST="boot.cmd"
VERSION=24.2.0-trunk.540
REVISION=24.2.0-trunk.540
IMAGE_UUID=5774cefd-8728-4d69-8504-636e97a35e54
# PLEASE DO NOT EDIT THIS FILE
BOARD=orangepipc
BOARD_NAME="Orange Pi PC"
BOARDFAMILY=sun8i
BUILD_REPOSITORY_URL=https://github.com/armbian/build
BUILD_REPOSITORY_COMMIT=a7aafb8de
LINUXFAMILY=sunxi
ARCH=arm
IMAGE_TYPE=nightly
BOARD_TYPE=csc
INITRD_ARCH=arm
KERNEL_IMAGE_TYPE=zImage
FORCE_BOOTSCRIPT_UPDATE=
FORCE_UBOOT_UPDATE=
VENDOR="Armbian"
VENDORDOCS="https://docs.armbian.com"
VENDORURL="https://www.armbian.com/"
VENDORSUPPORT="https://forum.armbian.com"
VENDORBUGS="https://www.armbian.com/bugs"
BOOTSCRIPT_FORCE_UPDATE="no"
BOOTSCRIPT_DST="boot.cmd"
VERSION=24.2.0-trunk.551
REVISION=24.2.0-trunk.551
BRANCH=current
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=22.04
DISTRIB_CODENAME=jammy
DISTRIB_DESCRIPTION="Ubuntu 22.04.3 LTS"
PRETTY_NAME="Armbian 24.2.0-trunk.551 jammy"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.3 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.armbian.com"
SUPPORT_URL="https://forum.armbian.com"
BUG_REPORT_URL="https://www.armbian.com/bugs"
PRIVACY_POLICY_URL="https://www.armbian.com"
UBUNTU_CODENAME=jammy
ARMBIAN_PRETTY_NAME="Armbian 24.2.0-trunk.551 jammy"

 

Edited by Crossplatform Vlad
Posted (edited)
6 часов назад, Crossplatform Vlad сказал:

Not exactly. trim and fstrim works well on the same SSD connected to USB 3.* on laptop using the same USB-SATA adapter. I didn't connect SSD to a sata connecor directly. 

But trim is missing on USB 2.0 only orange pi pc.

I need time to think.

 

P.S. Test:

OS openSUSE 15.4, desktop computer

SATA3 <-> SSD_SATA3

sudo fstrim -v /   good work
 

USB2.0 <-> USB2-SATA_adaptor <->SSD_SATA3

fstrim: /mnt: the discard operation is not supported
 

USB2.0 <-> USB3-SATA_adaptor <->SSD_SATA3

fstrim: /mnt: the discard operation is not supported

 

USB3.0 <-> USB3-SATA_adaptor <->SSD_SATA3

fstrim: /mnt: the discard operation is not supported

 

> sudo mount -v -o rw,noatime,nodiratime,discard,errors=remount-ro,commit=600 /dev/sdf1 /mnt
> sudo mount | grep /mnt
/dev/sdf1 on /mnt type ext4 (rw,noatime,nodiratime,discard,errors=remount-ro,commit=600)
> sudo fstrim -v /mnt
fstrim: /mnt: the discard operation is not supported

 

I think it's some kind of hardware limitation.
You have a newer generation USB3-SATA3 adapter and it supports the function when connected to a USB3 port.

Mine is not.

 

Armbian has nothing to do with this.

@Crossplatform Vlad I intentionally ran the test on my work computer, not on a banana.

Edited by going
Add P.S.
Posted (edited)
22 hours ago, going said:

You have a newer generation USB3-SATA3 adapter and it supports the function when connected to a USB3 port.

Mine is not.

Yeah. RTL9201 is a pretty new controller. Ubuntu 22.04 was released early. I'm waiting for Ubuntu 24.04 based armbian. 

 

 

22 hours ago, going said:

I think it's some kind of hardware limitation.

But USB 2.0 sata controllers support TRIM without queueing according to Google. 

Probably fstrim unconditionally needs queueing and fails. 

How to check that continuing trimming works despite fstrim doesn't?

Edited by Crossplatform Vlad
Posted
50 минут назад, Crossplatform Vlad сказал:

But USB 2.0 sata controllers support TRIM without queueing according to Google.

Okay, let's move on.

 

When I mount an ext4 FS, sudo mount -v -o rw,noatime,nodiratime,discard,errors=remount-ro,commit=600 /dev/sdf1 /mnt

dmesg reports:

[28422.686388] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[28422.717550] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: errors=remount-ro. Quota mode: none.
[28612.985794] EXT4-fs (sdf1): mounting with "discard" option, but the device does not support discard
[28612.985800] EXT4-fs (sdf1): mounted filesystem with ordered data mode. Opts: discard,errors=remount-ro,commit=600. Quota mode: none.

 

When I mount an btrfs FS, sudo mount -o rw,relatime,ssd,space_cache,subvolid=5,subvol=/ /dev/sdf /mnt
dmesg reports:

[35708.200591] BTRFS: device label test-btrfs devid 1 transid 5 /dev/sdf scanned by mkfs.btrfs (24307)
[35708.283831] BTRFS info (device sdf): disk space caching is enabled
[35708.283837] BTRFS info (device sdf): has skinny extents
[35708.283839] BTRFS info (device sdf): flagging fs with big metadata feature
[35708.286642] BTRFS info (device sdf): checking UUID tree
[36135.461701] BTRFS info (device sdf): disk space caching is enabled
[36135.461706] BTRFS info (device sdf): has skinny extents
[36268.307315] BTRFS info (device sdf): enabling ssd optimizations
[36268.307322] BTRFS info (device sdf): disk space caching is enabled
[36268.307324] BTRFS info (device sdf): has skinny extents

EXT4 reports that there is no trim support.

BTRFS informs you that everything is included.

Perhaps I am mistaken and this is the presence/absence of support in the kernel drivers.

 

I have two more devices, adapters for SATA.
One is directly soldered to the BPI-M3. The other is an external PCIe-SATA.
I'll check them later.

Posted
1 час назад, Crossplatform Vlad сказал:

How to check that continuing trimming works despite fstrim doesn't?

 

Maybe we should first discuss what is driving your desire in this direction? What is the ultimate goal?

Posted (edited)
57 minutes ago, going said:

Maybe we should first discuss what is driving your desire in this direction? What is the ultimate goal?

 

1. performance

2. smooth responsiveness. 

 

image.thumb.png.b0ceb18018ce8f434a0fffeefb920628.png

 

For USB 2.0 SSD reading is 2x (2944 vs 1500) faster than microsd, and writing is 8x faster (3942 vs 500) than microsd.
The benchmark above is made on orange pi pc. 

 

3. missing performance degradation on SSD over time if trim is working

 

 

Edited by Crossplatform Vlad
Posted
2 минуты назад, Crossplatform Vlad сказал:

3. missing performance degradation over time if trim is working.

This is a key importance for me and for you.

 

Perhaps some hints exist in man fstrim

 

On my SSD, which is 50% full, the slowdown is observed after about 2 months. I just run the command in this case and wait (do nothing).

This repeats itself when I start to observe a slowdown.

 

To be honest, I do not know of any other tool for this functionality than dmesg messages when mounting a file system.

Posted
17 hours ago, going said:

To be honest, I do not know of any other tool for this functionality than dmesg messages when mounting a file system.

On my orange pi pc there are no any errors on missing discard support. it says turning on sync discard 🥳

 

[    7.831505] BTRFS info (device sda1: state M): turning on sync discard
[    7.831553] BTRFS warning (device sda1: state M): excessive commit interval 600
[    7.831581] BTRFS info (device sda1: state M): use lzo compression, level 0

 

Does it mean continuing trimming works despite fstrim doesn't?

  • Solution
Posted
5 часов назад, Crossplatform Vlad сказал:

On my orange pi pc there are no any errors on missing discard support. it says turning on sync discard 🥳

 

[    7.831505] BTRFS info (device sda1: state M): turning on sync discard
[    7.831553] BTRFS warning (device sda1: state M): excessive commit interval 600
[    7.831581] BTRFS info (device sda1: state M): use lzo compression, level 0

 

Does it mean continuing trimming works despite fstrim doesn't?

In this case, the TRIM will be continuous and implemented directly by the kernel.

 

P.S. More info:

Solid_state_drive

 

I don't have anything to add to this article.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines