Date: Sat, 17 Feb 2024 16:21:14 +0000 From: Ordinary Bit <ordinarybit@proton.me> To: Mark Millard <marklmi@yahoo.com> Cc: Ronald Klop <ronald-lists@klop.ws>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: newfs TRIM flag device support Message-ID: <zlZ2Mri1Mx99HOY1z1WXazEOCID5CWKwwmgvOVYDCmxWwSyxpK1LIZfvFcUPN9-aV9AVskZ9lMiUXNCHTZaPK1wz-KTEKtmZdyVbksSfJ90=@proton.me> In-Reply-To: <1B0C2E27-6776-40A1-A8BF-29094FF8FC03@yahoo.com> References: <zBjNO8pJgkvHeMFBa74-f89m7IO_mgcHccwonGg0sZNJtDds49EICbFezJwbGJYnQDSVEI_tm3vCG4pjpdwiNyAtfF9lYfAn9znBR2I0AMQ=@proton.me> <8D8AA3F5-74A3-4AFE-A560-F52C7C55CF12@yahoo.com> <7okx4eDPse2uF1n3aX4W8RIOdbHXziUhqgvHxqqxpYN-7NsJfEGrfHbDxLgNS3PdOwZt7j9aOXp-0MHDjQAryL4t1Gd2QHUG1sFNmd5dY0k=@proton.me> <454941689.1180.1708079489598@localhost> <VCao0qH9-9Ie88pJtfOTzurWaPFxGEKRaZZL8zSjKaaM2hEQIB8R1p8kB7Cc7PvB7NK0Df0XrDamMZFx3PJlT85t6QVBm4T0leqvJA0MdF4=@proton.me> <nMflyJQojjrvtvJlZ2Re4YFpszk2lUaFkiZjtWguBRzji81TTjSKq-1z-PTZrYhW33lARfF0CPs0Nck4z3yQEH6pjLFKOt91F8NiLKogOQQ=@proton.me> <59693EE7-0DD6-4B41-BA64-0F3D69D3ECC9@yahoo.com> <bVPrJeknNzb33PLpaM2c4eJyCtFuENc2rqG2-n-9Za44UOyMq5Ot15UYC0JMckCYvlQ-n0IejdSlMEUcTfp0OeaSqR4dWCYGc7Z-a7CdkdE=@proton.me> <1B0C2E27-6776-40A1-A8BF-29094FF8FC03@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, 17 February 2024 at 23:20, Mark Millard <marklmi@yahoo.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?zlZ2Mri1Mx99HOY1z1WXazEOCID5CWKwwmgvOVYDCmxWwSyxpK1LIZfvFcUPN9-aV9AVskZ9lMiUXNCHTZaPK1wz-KTEKtmZdyVbksSfJ90=>