Re: newfs TRIM flag device support

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 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.
>>
>
> Yeah, thanks for the help Mark! My latest testing were also showing Raspberry 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/mmcsd03 on /mnt.
>>>
>>> root@sd-ultra:~ # gpart show -p
>>> => 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 only 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)
>>>
>>> => 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 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.
>>>
>>> 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 activity, 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 TRIM 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 provided but at last it's proven. Thanks once again!
>
> BR,
> orbit