From nobody Sat Feb 17 16:21:14 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TcYvn04cDz5BR2V for ; Sat, 17 Feb 2024 16:21:25 +0000 (UTC) (envelope-from ordinarybit@proton.me) Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TcYvm4KS8z4mRS for ; Sat, 17 Feb 2024 16:21:24 +0000 (UTC) (envelope-from ordinarybit@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=vo4slgzljvhubgtgwclqig63ly.protonmail; t=1708186881; x=1708446081; bh=qb4s+J/9oUk5mWbIwbjaVhlkBz9XBkdp1gieDIJ35Yg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=NVc1v9T3pHF9VY9ktoTxNU/bSdz/0d8cG+vE2I4jEceQVyjSalm58T74Eumd5hkhD f32M/q4RiMXZw5E78MmtyKCQo8RWRc8e4chSnlD4ZhipqI9rn5BpgbU6yZTfEdH2QB r7imhhPrl+MvwtH0mAUDedVjYZW6pa+LabXQezWBc1MP1CXXIHuRlnw+puKvB3bN+l 2KhxBtf4qyNmRPbWe+6RVcKd+ZablkmRCkQVU17mJmExsPAHZIO07lkuXDePK6tE4h 43OC7bOBa5V0fOqekR7NcnLXqRo3QeNIi6AuuOb6on7DmqyLR9G7OwpFS8wrzScPMr xl56DZ919mkEA== Date: Sat, 17 Feb 2024 16:21:14 +0000 To: Mark Millard From: Ordinary Bit Cc: Ronald Klop , "freebsd-arm@freebsd.org" Subject: Re: newfs TRIM flag device support Message-ID: In-Reply-To: <1B0C2E27-6776-40A1-A8BF-29094FF8FC03@yahoo.com> References: <8D8AA3F5-74A3-4AFE-A560-F52C7C55CF12@yahoo.com> <7okx4eDPse2uF1n3aX4W8RIOdbHXziUhqgvHxqqxpYN-7NsJfEGrfHbDxLgNS3PdOwZt7j9aOXp-0MHDjQAryL4t1Gd2QHUG1sFNmd5dY0k=@proton.me> <454941689.1180.1708079489598@localhost> <59693EE7-0DD6-4B41-BA64-0F3D69D3ECC9@yahoo.com> <1B0C2E27-6776-40A1-A8BF-29094FF8FC03@yahoo.com> Feedback-ID: 100108111:user:proton List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4TcYvm4KS8z4mRS X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] On Saturday, 17 February 2024 at 23:20, Mark Millard wr= ote: > On Feb 17, 2024, at 02:39, Ordinary Bit ordinarybit@proton.me wrote: >=20 > > > > Confirmed, the SanDisk Ultra microSD does not support TRIM using th= e microSD slot in both Raspberry Pi 3 and 4. Instead of building an image f= rom scratch, I downloaded a FreeBSD 14.0 image and created a new partition = (8GB in size) with UFS/FFS with TRIM enabled and mount it. The partition is= /dev/mmcsd0s3. There's no delete activity observed with "gstat -d" when I = deleted some files in it. >=20 >=20 > My notes were bad by not saying how to force FreeBSD to > actually do the file system updates (sync use). But you > got the evidence that you were looking for anyway: you > have now seen evidence of the TRIM activity when the > microsd card is in the built-in slot on a RPi* . >=20 > Below, you showed the SanDisk Ultra microSD doing > TRIM activity. > Yeah, thanks for the help Mark! My latest testing were also showing Raspber= ry Pi 3B performed TRIM activity. So, both Raspberry Pi 3B and 4B can do TR= IM with SanDisk Ultra microSD using their built-in slots. =20 > > > You do not show the console output for the mount of > > > /dev/mmcsd0s3 on /mnt. Did it show: > > >=20 > > > WARNING: /mnt: TRIM flag on fs but disk does not support TRIM > > >=20 > > > ? > >=20 > > No, it didn't show up in the dmesg output after I mounted /dev/mmcsd03 = on /mnt. > >=20 > > root@sd-ultra:~ # gpart show -p > > =3D> 63 124735425 mmcsd0 MBR (59G) > > 63 1985 - free - (993K) > > 2048 102400 mmcsd0s1 fat32lba [active] (50M) > > 104448 10381312 mmcsd0s2 freebsd (5.0G) > > 10485760 16777216 mmcsd0s3 freebsd (8.0G) >=20 >=20 > An oddity just above is that mmcsd0s3 is not set to the > type freebsd-ufs . But the oddity does not mess up the > testing you were doing. > Let me test this one with freebsd-ufs type because you're right it's only f= reebsd. =20 > > 27262976 97472512 - free - (46G) > >=20 > > =3D> 0 10381312 mmcsd0s2 BSD (5.0G) > > 0 128 - free - (64K) > > 128 10381184 mmcsd0s2a freebsd-ufs (4.9G) > >=20 > > . . . > > root@sd-ultra:~ # mount /dev/mmcsd0s3 /mnt > > root@sd-ultra:~ # > > root@sd-ultra:~ # dmesg | grep TRIM > > root@sd-ultra:~ # dmesg | grep trim >=20 >=20 > The above is evidence that TRIM is supported for the > combination in use. > > > . . . > >=20 > > Did I missed something here? but when the microSD card is inserted in m= y USB reader, then it shows this up --> WARNING: /mnt: TRIM flag on fs but = disk does not support TRIM. >=20 >=20 > I already wrote that the combination FreeBSD+USB-reader/writer > normally does not support TRIM for any microsd card. This is > normal. >=20 > > > . . . > > > . . . > > > root@sd-ultra:/mnt # cp file01 file02 >=20 >=20 > I should have noted that the actual file I/O can continue > to happen after the shell gets to the next prompt. Using > a larger enough file can be a good technique of allowing > gstat to be run after a cp or rm command but to see > activity in the later gstat. > Got it, I can do test with this scenario too. =20 > > . . . > >=20 > > root@sd-ultra:/mnt # ls -lah > > total 5684108 > > drwxr-xr-x 3 root wheel 512B Feb 11 13:04 . > > drwxr-xr-x 21 root wheel 512B Feb 11 14:13 .. > > drwxrwxr-x 2 root operator 512B Feb 11 14:57 .snap > > -rw-r--r-- 1 root wheel 1.4G Feb 11 17:20 file01 > > -rw-r--r-- 1 root wheel 1.4G Feb 11 12:56 file02 > >=20 > > and then delete the files with rm > >=20 > > root@sd-ultra:/mnt # rm * > >=20 > > Executing delete is very fast and waited for a little bit more then sud= denly I observed mmcsd0 and mmcsd0s3 showing deleting of data. This is the = first time I found. How about this one? It's a one time show and I never fi= nd another stats after this interval. > >=20 > > root@sd-ultra:/mnt # gstat -d > > dT: 1.028s w: 1.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > > 22 422 14 436 71.8 0 0 0.0 409 1613422 38.6 96.7| mmcsd0 > > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| mmcsd0s1 > > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| mmcsd0s2 > > 5 41 14 436 71.9 0 0 0.0 27 1637328 76.7 98.0| mmcsd0s3 > > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| msdosfs/EFI > > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| mmcsd0s2a > > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| ufs/rootfs >=20 >=20 > The above gives evidence of specific TRIM activity happening. > Alright! =20 > > > > . . . > > >=20 > > > # sysctl -a | grep -i trim > > >=20 > > > ? (TRIM is sometimes in capitals.) > > >=20 > > > # dmesg -a | grep -i trim > > >=20 > > > ? > >=20 > > No output results. > >=20 > > root@sd-ultra:~ # dmesg | grep trim > > root@sd-ultra:~ # dmesg | grep TRIM >=20 >=20 > The above afer the mount is evidence that TRIM is supported > for the combination in use. >=20 > > > . . . > > >=20 > > > It looks to me like the testing procedure may have been > > > flawed. > >=20 > > Maybe but upon re-testing I already found this gstat deleting activity,= this is after I executed rm to the 2 files as I stated above. > >=20 > > root@sd-ultra:/mnt # gstat -d > > dT: 1.028s w: 1.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > > 22 422 14 436 71.8 0 0 0.0 409 1613422 38.6 96.7| mmcsd0 > > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| mmcsd0s1 > > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| mmcsd0s2 > > 5 41 14 436 71.9 0 0 0.0 27 1637328 76.7 98.0| mmcsd0s3 > > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| msdosfs/EFI > > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| mmcsd0s2a > > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| ufs/rootfs > >=20 > > If still not the expected outcome, do you have procedures how did TRIM = happened in your simulation? >=20 >=20 > It is as expected. You got a good sequence of well timed test steps > this time. >=20 Apologize for the confusion of my first test with poor documentation provid= ed but at last it's proven. Thanks once again! BR, orbit