Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 17 Feb 2024 10:39:19 +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:  <bVPrJeknNzb33PLpaM2c4eJyCtFuENc2rqG2-n-9Za44UOyMq5Ot15UYC0JMckCYvlQ-n0IejdSlMEUcTfp0OeaSqR4dWCYGc7Z-a7CdkdE=@proton.me>
In-Reply-To: <59693EE7-0DD6-4B41-BA64-0F3D69D3ECC9@yahoo.com>
References:  <zBjNO8pJgkvHeMFBa74-f89m7IO_mgcHccwonGg0sZNJtDds49EICbFezJwbGJYnQDSVEI_tm3vCG4pjpdwiNyAtfF9lYfAn9znBR2I0AMQ=@proton.me> <6AD380D4-9B42-4511-9E02-94EB0005D278@yahoo.com> <DL-bGuTxmOC5O2N-3wa9mbkuJ6VMeRTrwiHT_eOaHeopBXr_JfbRiHKiiyncADaXrn8H575uLNIkdxjNV0Nogz3IJuVfE_T8jcU30voSkYI=@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>

next in thread | previous in thread | raw e-mail | index | archive | help
> >=20
> > Confirmed, the SanDisk Ultra microSD does not support TRIM using the mi=
croSD 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 /de=
v/mmcsd0s3. There's no delete activity observed with "gstat -d" when I dele=
ted some files in it.
>=20
>=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
> ?

No, it didn't show up in the dmesg output after I mounted /dev/mmcsd03 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)
   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 -lv
/dev/ufs/rootfs on / (ufs, local, soft-updates, writes: sync 454 async 3046=
, reads: sync 38935 async 3, fsid 89fc4d652aba17cd, vnodes: count 542 )
devfs on /dev (devfs, fsid 00ff007171000000, vnodes: count 34 )
/dev/msdosfs/EFI on /boot/efi (msdosfs, local, noatime, writes: sync 1 asyn=
c 0, reads: sync 8 async 0, fsid 5c00000032000000, vnodes: count 1 )
tmpfs on /tmp (tmpfs, local, fsid 01ff008787000000, vnodes: count 6 )
root@sd-ultra:~ #
root@sd-ultra:~ # mount /dev/mmcsd0 (pressing Tab key)
/dev/mmcsd0     /dev/mmcsd0s1   /dev/mmcsd0s2   /dev/mmcsd0s2a  /dev/mmcsd0=
s3
root@sd-ultra:~ # mount /dev/mmcsd0s3 /mnt
root@sd-ultra:~ #
root@sd-ultra:~ # dmesg | grep TRIM
root@sd-ultra:~ # dmesg | grep trim

root@sd-ultra:~ # mount -lv
/dev/ufs/rootfs on / (ufs, local, soft-updates, writes: sync 458 async 3065=
, reads: sync 38935 async 3, fsid 89fc4d652aba17cd, vnodes: count 542 )
devfs on /dev (devfs, fsid 00ff007171000000, vnodes: count 34 )
/dev/msdosfs/EFI on /boot/efi (msdosfs, local, noatime, writes: sync 1 asyn=
c 0, reads: sync 8 async 0, fsid 5c00000032000000, vnodes: count 1 )
tmpfs on /tmp (tmpfs, local, fsid 01ff008787000000, vnodes: count 6 )
/dev/mmcsd0s3 on /mnt (ufs, local, soft-updates, writes: sync 2 async 0, re=
ads: sync 3 async 0, fsid 4ee0c86506330890, vnodes: count 2 )

Did I missed something here? but when the microSD card is inserted in my US=
B reader, then it shows this up --> WARNING: /mnt: TRIM flag on fs but disk=
 does not support TRIM. =20

>=20
> You do not show creating or deleting files. gstat does not
> give running totals. Your gstat output shown was only for a
> single 1.065s interval. Did you start the delete during that
> interval with enough time for the delete to happen during
> that interval? If not, the command output has no such
> implications.
>

While redoing the test with the same procedures, I do have a file with size=
 of 1.4G replicated as file01, file02 in the /mnt (/dev/mmcsd0s3). While re=
plicating, gstat shows intervals of reading and writing.

root@sd-ultra:/mnt # pwd
/mnt

root@sd-ultra:/mnt # cp file01 file02

root@sd-ultra:/mnt # gstat -d
dT: 1.003s  w: 1.000s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w    d/s   kBps   ms/d=
   %busy Name
    0    449    449  14358    2.1      0      0    0.0      0      0    0.0=
   94.0| 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
    0    449    449  14358    2.1      0      0    0.0      0      0    0.0=
   94.5| 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

root@sd-ultra:/mnt # gstat -d
dT: 1.046s  w: 1.000s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w    d/s   kBps   ms/d=
   %busy Name
    4     15      0      0    0.0     15  15665  229.3      0      0    0.0=
  100.0| 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
    4     16      0      0    0.0     16  16644  227.6      0      0    0.0=
  105.8| 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

root@sd-ultra:/mnt # gstat -d
dT: 1.017s  w: 1.000s
 L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w    d/s   kBps   ms/d=
   %busy Name
    4     50     35   1133    2.1     15  14478  200.3      0      0    0.0=
   99.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
    4     50     35   1133    2.1     15  14478  200.3      0      0    0.0=
   99.8| 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

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 suddenl=
y I observed mmcsd0 and mmcsd0s3 showing deleting of data. This is the firs=
t time I found. How about this one? It's a one time show and I never find a=
nother 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

> gstat has a command line option that allows specifying a
> longer interval. The deletes should be started and completed
> during the interval in order to see the counts for the
> deletes.
>=20
> I'll note that the SanDisk Ultra microSD cards that I use
> do TRIM when in the microsd card slots of the RPi4's I have
> access to.
>
> > root@sd-extreme:~ # /sbin/gpart add -s 8G -t freebsd da0
> > da0s3 added
>=20
> /dev/da0 is not the microsd card slot, but a USB device.
>=20
> > root@sd-extreme:~ # gpart show
>=20
>=20
>=20
> The result would be easier to track with
>=20
> # gpart show -p
>=20
> That would show notation that could be used after
> /dev/ instead of index numbers.
>=20
> > =3D> 63 124735425 mmcsd0 MBR (59G)
> > 63 1985 - free - (993K)
> > 2048 102400 1 fat32lba [active] (50M)
> > 104448 124626944 2 freebsd (59G)
> > 124731392 4096 - free - (2.0M)
> >=20
> > =3D> 0 124626944 mmcsd0s2 BSD (59G)
> > 0 128 - free - (64K)
> > 128 120833920 1 freebsd-ufs (58G)
> > 120834048 3792896 2 freebsd-swap (1.8G)
>=20
>=20
> There is no /dev/mmcsd0s3 above.
>=20
> > =3D> 63 124735425 da0 MBR (59G)
> > 63 1985 - free - (993K)
> > 2048 102400 1 fat32lba [active] (50M)
> > 104448 10381312 2 freebsd (5.0G)
> > 10485760 16777216 3 freebsd (8.0G)
> > 27262976 97472512 - free - (46G)
>=20
>=20
> There is a /dev/da0s3 already existing above. But
> it is not (yet) freebsd-ufs.
>=20
> > =3D> 0 10381312 da0s2 BSD (5.0G)
> > 0 128 - free - (64K)
> > 128 10381184 1 freebsd-ufs (4.9G)
>=20
>=20
> That freebsd-ufs is /dev/da0s2a .
>=20
> > =3D> 63 124735425 diskid/DISK-121220160204 MBR (59G)
> > 63 1985 - free - (993K)
> > 2048 102400 1 fat32lba [active] (50M)
> > 104448 10381312 2 freebsd (5.0G)
> > 10485760 16777216 3 freebsd (8.0G)
> > 27262976 97472512 - free - (46G)
> >=20
> > =3D> 0 10381312 diskid/DISK-121220160204s2 BSD (5.0G)
> > 0 128 - free - (64K)
> > 128 10381184 1 freebsd-ufs (4.9G)
> >=20
> > root@sd-extreme:~ # ls -lah /dev/da0
> > /dev/da0 /dev/da0s1 /dev/da0s2 /dev/da0s2a /dev/da0s3
> >=20
> > root@sd-extreme:~ # newfs -U -t /dev/da0s3
>=20
>=20
> /dev/da0s3 is not in the microsd card slot, but on a USB device.
>=20
> > /dev/da0s3: 8192.0MB (16777216 sectors) block size 32768, fragment size=
 4096
> > using 14 cylinder groups of 625.22MB, 20007 blks, 80128 inodes.
> > with soft updates
> > super-block backups (for fsck_ffs -b #) at:
> > 192, 1280640, 2561088, 3841536, 5121984, 6402432, 7682880, 8963328, 102=
43776, 11524224, 12804672, 14085120,
> > 15365568, 16646016
> >=20
> > root@sd-ultra:~ # gpart show -l
> > =3D> 63 124735425 mmcsd0 MBR (59G)
> > 63 1985 - free - (993K)
> > 2048 102400 1 (null) [active] (50M)
> > 104448 10381312 2 (null) (5.0G)
> > 10485760 16777216 3 (null) (8.0G)
> > 27262976 97472512 - free - (46G)
> >=20
> > =3D> 0 10381312 mmcsd0s2 BSD (5.0G)
> > 0 128 - free - (64K)
> > 128 10381184 1 (null) (4.9G)
>=20
>=20
> Looks like you moved the microsd card to the microsd card
> slot from the usb device?
>

Sorry for the confusion, I dd'ed the FreeBSD 14 image from my @sd-extreme (=
a Rasberry Pi 3 host) where my SanDisk microSD is inserted in a USB reader =
and then after the installer had been created I also created the new partit=
ion which is the /dev/da0s3 having UFS/FFS plus the TRIM flag enabled. I al=
so mounted the rootfs /dev/da0s2a to modify the /etc/rc.conf and remove the=
 firstboot file to intervene auto-resize of the default rootfs FS size. Fro=
m here, I moved the microsSD card from @sd-extreme and insert it into my Ra=
spberry Pi 4 microSD slot with hostname @sd-ultra. From here, partitions ch=
anged from /dev/da0* to /dev/mmcsd0*.=20

> > root@sd-ultra:~ # mount -l
> > /dev/ufs/rootfs on / (ufs, local, soft-updates)
> > devfs on /dev (devfs)
> > /dev/msdosfs/EFI on /boot/efi (msdosfs, local, noatime)
> > tmpfs on /tmp (tmpfs, local)
> > /dev/mmcsd0s3 on /mnt (ufs, local, soft-updates)
> >=20
> > root@sd-ultra:~ # gstat -d
>=20
>=20
> When did you create and delete the files?
>=20
> > dT: 1.065s w: 1.000s
>=20
>=20
> During that 1.065s interval?
>=20
> > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
> > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| 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
> > 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.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
> > root@sd-ultra:~ # mount -l -v
> > /dev/ufs/rootfs on / (ufs, local, soft-updates, writes: sync 838 async =
4316, reads: sync 2241 async 2697, fsid 89fc4d652aba17cd, vnodes: count 126=
4 )
> > devfs on /dev (devfs, fsid 00ff007171000000, vnodes: count 34 )
> > /dev/msdosfs/EFI on /boot/efi (msdosfs, local, noatime, writes: sync 1 =
async 0, reads: sync 8 async 0, fsid 5b00000032000000, vnodes: count 1 )
> > tmpfs on /tmp (tmpfs, local, fsid 01ff008787000000, vnodes: count 6 )
> > /dev/mmcsd0s3 on /mnt (ufs, local, soft-updates, writes: sync 2 async 7=
866, reads: sync 121491 async 0, fsid 4ee0c86506330890, vnodes: count 3 )
> >=20
> > root@sd-ultra:~ # sysctl -a | grep trim
>=20
>=20
> # sysctl -a | grep -i trim
>=20
> ? (TRIM is sometimes in capitals.)
>=20
> # dmesg -a | grep -i trim
>=20
> ?

No output results.

root@sd-ultra:~ # dmesg | grep trim
root@sd-ultra:~ # dmesg | grep TRIM

>=20
> > <118>Creating and/or trimming log files.
> > kern.cam.nda.max_trim: 256
> > vfs.ffs.dotrimcons: 1
> >=20
> > I'll proceed with plan B, to buy industrial grade microSD card having a=
 garbage collection feature in the controller instead of this consumer grad=
e card. Either TRIM will work or not there's still garbage collection I cou=
ld benefit.
>=20
>=20
> It looks to me like the testing procedure may have been
> flawed.
>

Maybe but upon re-testing I already found this gstat deleting activity, thi=
s 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 happ=
ened in your simulation?

BR,
orbit



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bVPrJeknNzb33PLpaM2c4eJyCtFuENc2rqG2-n-9Za44UOyMq5Ot15UYC0JMckCYvlQ-n0IejdSlMEUcTfp0OeaSqR4dWCYGc7Z-a7CdkdE=>