Re: newfs TRIM flag device support

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.

>> 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.

>   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.

> . . .
> 
> 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.

>>> . . .
>> 
>> 
>> # 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.

===
Mark Millard
marklmi at yahoo.com