Date: Sat, 17 Feb 2024 10:44:19 -0600 From: Mike Karels <mike@karels.net> To: Ordinary Bit <ordinarybit@proton.me> Cc: Mark Millard <marklmi@yahoo.com>, Ronald Klop <ronald-lists@klop.ws>, freebsd-arm@freebsd.org Subject: Re: newfs TRIM flag device support Message-ID: <F12979C1-55EF-4AC3-88D9-5CE7236F3AD3@karels.net> In-Reply-To: <zlZ2Mri1Mx99HOY1z1WXazEOCID5CWKwwmgvOVYDCmxWwSyxpK1LIZfvFcUPN9-aV9AVskZ9lMiUXNCHTZaPK1wz-KTEKtmZdyVbksSfJ90=@proton.me> 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> <zlZ2Mri1Mx99HOY1z1WXazEOCID5CWKwwmgvOVYDCmxWwSyxpK1LIZfvFcUPN9-aV9AVskZ9lMiUXNCHTZaPK1wz-KTEKtmZdyVbksSfJ90=@proton.me>
next in thread | previous in thread | raw e-mail | index | archive | help
On 17 Feb 2024, at 10:21, Ordinary Bit wrote: > On Saturday, 17 February 2024 at 23:20, Mark Millard <marklmi@yahoo.com= > wrote: > >> On Feb 17, 2024, at 02:39, Ordinary Bit ordinarybit@proton.me wrote: >> >>>>> 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= from scratch, I downloaded a FreeBSD 14.0 image and created a new partit= ion (8GB in size) with UFS/FFS with TRIM enabled and mount it. The partit= ion 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. >> > > Yeah, thanks for the help Mark! My latest testing were also showing Ras= pberry Pi 3B performed TRIM activity. So, both Raspberry Pi 3B and 4B can= do TRIM with SanDisk Ultra microSD using their built-in slots. > >>>> You do not show the console output for the mount of >>>> /dev/mmcsd0s3 on /mnt. Did it show: >>>> >>>> WARNING: /mnt: TRIM flag on fs but disk does not support TRIM >>>> >>>> ? >>> >>> No, it didn't show up in the dmesg output after I mounted /dev/mmcsd0= 3 on /mnt. >>> >>> 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. >> > > Let me test this one with freebsd-ufs type because you're right it's on= ly freebsd. freebsd-ufs is a GPT type; this is MBR. The ufs filesystem is presumably= mmcsd0s3a. If the filesystem gets mounted, the partitioning is OK. Mike >>> 27262976 97472512 - free - (46G) >>> >>> =3D> 0 10381312 mmcsd0s2 BSD (5.0G) >>> 0 128 - free - (64K) >>> 128 10381184 mmcsd0s2a freebsd-ufs (4.9G) >>> >>> . . . >>> 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. >> >>> . . . >>> >>> 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. >> >> >> 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. >> > > Got it, I can do test with this scenario too. > >>> . . . >>> >>> 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 >>> >>> and then delete the files with rm >>> >>> root@sd-ultra:/mnt # rm * >>> >>> Executing delete is very fast and waited for a little bit more then s= uddenly 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 ne= ver find another stats after this interval. >>> >>> 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. >> > > Alright! > >>>>> . . . >>>> >>>> # sysctl -a | grep -i trim >>>> >>>> ? (TRIM is sometimes in capitals.) >>>> >>>> # dmesg -a | grep -i trim >>>> >>>> ? >>> >>> No output results. >>> >>> 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. >> >>>> . . . >>>> >>>> It looks to me like the testing procedure may have been >>>> flawed. >>> >>> Maybe but upon re-testing I already found this gstat deleting activit= y, this is after I executed rm to the 2 files as I stated above. >>> >>> 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 >>> >>> If still not the expected outcome, do you have procedures how did TRI= M happened in your simulation? >> >> >> It is as expected. You got a good sequence of well timed test steps >> this time. >> > > Apologize for the confusion of my first test with poor documentation pr= ovided 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?F12979C1-55EF-4AC3-88D9-5CE7236F3AD3>