From nobody Sat Feb 17 15:20:52 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 4TcXZB5Xmnz5BH26 for ; Sat, 17 Feb 2024 15:21:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TcXZB3CGCz4dN3 for ; Sat, 17 Feb 2024 15:21:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1708183264; bh=Y77NbXQiFHmWZF4T6Eyk5HUrDWMqePrfxp/FJaLcPbw=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=mHjMBYECXj12vNi6RPaCOkbgLJZq+wfiB1AJHI8+QwEp/plrYcvbxavfAkhiRTn3f/WPt2QZk732HhNRXBnpQtF5lfdXyuEeught16B95baL/a/gkqVwhNE5TtYP8YDL7/U0Dfiy81v7cdZkTVMxVP7eGaK7MxxXwbOg7xvXPhFf4tua53eEXhetyetVQGADiXA0vicEDLJUb4iiByA5slXIUl+fgvMGA2I90Hzk8/uTwQy2gm/dTNxOg07KUZ9PNPpjmEgYRSOvfsY+r5NU84FAxaiZGtwceJ/mjAEpHjFBHpOv82AyvPVA4/ckGEMysxhDyk6Stokfcyo3gneEJw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1708183264; bh=gv1xdD7Y0r4qvYEghINV9ExvV4xj08rp/xmFKTu48Ku=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=CTq+divVFvTPENL/Irp0xZTT7XOPULhoO7310+LFswLmpwbnYqryWnBS/9uvwrWbqrWeBnyVvVi5qoK8inGj7v6ROrQtcEWFwjXKVmtElHEZVQ7Y289S4qr1CZXYslKqc3oHYbX8g9GqxFmHZTZrASzCfrmkuPGcdP3k5CU+hom7ZB27se3bFZlXuRKt+bUpkkHWH3QR6esJd4a9e2aU9vkeKN0QQGhdUT5oO+iGXZUlTG7rh5XsS7WVb7GWWWSyNu/JgkR8jpdEsGpauTiTvEp7fqObj6ITn6Bi+rv5QoJy8oatVYsFtCSevjnCjbSpkA1krXQmSzPzKO5v5VBJ6A== X-YMail-OSG: 7HY9oqsVM1nis0iLEAnuMVGas.wRZ0tkHtfHfcjyL5NIegLO.dpObCfb_ogxcag M7vtcYXOSSHFw3uG.Kd8p0Jh07m9KsXFZ_2EqX9AeaviJhKCyezCMT3.rz9JHkCn7IJUT4RGXLEK qiAa0u2bTTyl7m5jEuAoY56N1xAvEHODVgLq.iV.UO46oyqpmbj6WRCasuFuczDaO0lAdBtiFs53 5qsNvz6WAwotlX4yN7_1HAoKkK8C9uIc2_XNf3RYnG.Pd3xiSm6cJBdZE0xGH1Gzd5.NUECrM4h9 wpVIoGgEu1nPH1M93gGMlkO82opxQhn_Z8Ktk_7sHwiAx_RlYahwSqoIMPZco3Sgr2Dpu0LwqDvh rLqcZ.Y0n109VnVjoAHFoJf_8sPCNS2hIZFpoJoRDbZs_3Cm_j82eEMwrS3zD_Dwr5PgQUVyqLcT f3EoYGrn5K5NDzQVlu9MkuFjnQNIHScIdzGLpexXQ8XZFExUj2dPNg41CTJIwJvSDTADMXD568i. 7NRiQuIAHSdQ14uGzbFDQ8oCy8X_0kSuOHSkam.LwlPYNTkL6rA_O0UlPjyu5dJTALtdGH2pGrIE LhBXuFEm7ZXxWkchoyQHhHHG6_JeeX72v4sml5NrSH8AGtOElsIYGWzXSDBt2wPBN5QZhdkEzmiJ Kh1AVzIOSnb7J1chPhpUlAec9LMI89A3LVYvR1IsZ6pMVd.wzV6I_fBIUvT5kdAFpxGLqyLmKhs0 91B5UbVzaQQ4hNNDlvmLufFWAvZg_aWjjNZIGbR47JIIXzz.PTU1dJAzEqzlcQt6ChKkoyY0ke6w Kjw2if5d.tWjzJy86mxFyQnxaw5usjxWZJCH42h3bnmdLA2RHsZVDZLeFhVPgJztwxjvxhtMIS7R UyJ0QHNY5jJcGEDfb1VYOiAx6sGdkv0KdQuV8FEKZyAnJnFCWmXm_XNlrJ0NM_mKeurE7J4I5XOY OZvP3Jh7eyWVX3NzwQbDUvIKcLjSv.j6uszjL9JrwObmqNPEnc5.WrY2HSAMZeDmoYXV4OmEyHLM atK.iPNax.JhaET5tqcoqLPccDys0UHgQfJMzv7w03hS9auKLOAFoJ3DkpkEN5iJSAoJJQRLyflA mN6GGnK7idYwBVhjw4CXpqos1Ij3nF7UPOqtTZVTeL1NOrlVzqSktsLYGgEnQJtbvVALcFMIoHH0 HNQNxjoow3t_zqmkodVINAKQI_tFnozVz50lR1UbZEQRs.UQkOGQg0e9xcCcryNC1lANK.T6mscL _jpGmeAh6a7hvMdWQKXfvJRqFVPMLZEh1krpvCXdDPMerq4MoTBocaBt8CsG2CAo2RLWTL11RVTo 8GkEM8g2tI9y2dr5QrgVSCJC00k2dMbtRUvWO0ngbv2KzVkdrpWdUk7sKpfCzAh5TEmLPyKYFC_q QeewrEFMX2VD5QXjyt2SUD_EPhuseS1NNdQrOHBzeEMQwJPcIwXj9ZNwYkP1h0d9tOVBKYZH9qsB 68Y4NLMLU2s2.TgtHdUCm7avwsJS.48XROW6K1BSs8wczKK94xctKVQXFrTIa.hUKmJo9bR5wDGP seAtzelN18pl1E6vr92duat6cOWDxqG5f0UNyuGdcUVluHbqRLnzhTigsT_EdJqDTUjIeLbaQJay .LQktGXrAC6kdoWDeJ4yQP0cA8y2h9Xmga1ECM2CvvUnC4Idd8HpB0giwTOycg8OtVDY3GGuuOCJ DcM6hWFNkcXPtZV2WPC0UKV9lreM5f_ZkvnWLns9Q_6CN_jwIpQ4z0jdbJitu4KmSDyVXbVE2CdW OiWDeP_sCyjn4OisERPoX4Q2GcQq5K4VJi.Y514vJp.3whiqqF3b.u1VPumfJyAofz2dJf7W9HRD myVM5gA7pgPkVoDFWqchnyNkNWAHvPb0T6v3cZY.Avhb8En3XWZcyNU3ozaTTV4AV96dObmUaA5Q xiaQhHUmAotCbFBCEc0jCFlYlLI59MKPz7eD2Bkr8khTu5AOSut3hLqbhgFlsN9Dbm6GW_576uCu 1oZcu99yjTWJQRfvSsng92RsCx04KtW4pPoRu7BKWhcv9N4_gcPeNzCctteLo9bnumpxI5IZUnHA CK8TWliAJzDHZ5MzHIipxFff2duNHiIR.7CNKdcZ7HFD0vRGXjFkn7jKLqjqGnCvfZBDUT_6YiUN FhTLyax.rf3l.uEMBM97.ZzIO3unbALaR6hASnkh3FLGU8Cm4bbu6rHBhmH4k7LgdLzUGrvusJbd YCBwuM97_FcF9yM4gi6z._.ptCaiedHrzaW.Hw28BgX.CYEVyxl52rWPR8_paAHWEk.qFA2vunYp J X-Sonic-MF: X-Sonic-ID: 5511fe43-bec6-4df2-8c61-b43991710440 Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Sat, 17 Feb 2024 15:21:04 +0000 Received: by hermes--production-gq1-5c57879fdf-qprqq (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 3376f75d834121a6e4d4f9505cc3e8f2; Sat, 17 Feb 2024 15:21:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: newfs TRIM flag device support From: Mark Millard In-Reply-To: Date: Sat, 17 Feb 2024 07:20:52 -0800 Cc: Ronald Klop , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1B0C2E27-6776-40A1-A8BF-29094FF8FC03@yahoo.com> References: <6AD380D4-9B42-4511-9E02-94EB0005D278@yahoo.com> <8D8AA3F5-74A3-4AFE-A560-F52C7C55CF12@yahoo.com> <7okx4eDPse2uF1n3aX4W8RIOdbHXziUhqgvHxqqxpYN-7NsJfEGrfHbDxLgNS3PdOwZt7j9aOXp-0MHDjQAryL4t1Gd2QHUG1sFNmd5dY0k=@proton.me> <454941689.1180.1708079489598@localhost> <59693EE7-0DD6-4B41-BA64-0F3D69D3ECC9@yahoo.com> To: Ordinary Bit X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4TcXZB3CGCz4dN3 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:36647, ipnet:98.137.64.0/20, country:US] On Feb 17, 2024, at 02:39, Ordinary Bit wrote: >=20 >>>=20 >>> Confirmed, the SanDisk Ultra microSD does not support TRIM using the = microSD slot in both Raspberry Pi 3 and 4. Instead of building an image = from 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. 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* . Below, you showed the SanDisk Ultra microSD doing TRIM activity. >> 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) 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. > 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 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 = my USB reader, then it shows this up --> WARNING: /mnt: TRIM flag on fs = but disk does not support TRIM. =20 I already wrote that the combination FreeBSD+USB-reader/writer normally does not support TRIM for any microsd card. This is normal. >> . . . > . . . > root@sd-ultra:/mnt # cp file01 file02 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. > . . . >=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 = suddenly 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 find 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 The above gives evidence of specific TRIM activity happening. >>> . . . >>=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 The above afer the mount is evidence that TRIM is supported for the combination in use. >> . . . >>=20 >> It looks to me like the testing procedure may have been >> flawed. >>=20 >=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? It is as expected. You got a good sequence of well timed test steps this time. =3D=3D=3D Mark Millard marklmi at yahoo.com