From nobody Sat Feb 17 10:39:19 2024 X-Original-To: freebsd-arm@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TcQKR2SMvz5B1Ff for ; Sat, 17 Feb 2024 10:39:39 +0000 (UTC) (envelope-from ordinarybit@proton.me) Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TcQKQ4krNz42RW for ; Sat, 17 Feb 2024 10:39:38 +0000 (UTC) (envelope-from ordinarybit@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1708166374; x=1708425574; bh=DEIjm5Fv+ceuqiuEh6JqJC2htNZS7km3riokd66FURQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=S9tfhs+LILhYyswCVXXkd20mm95EtNMdpYVcJuQlzEmX805Bi9LE07aGLZj8SYDtW 9HkHO7DrLDOc0Fi7hYM7r+0d0Na6mqzXAOurL35w2eE/55xT8GAKk7W2ztUtRO09wX mIRV+3zQvuWioQRmwGlGaBQH4Fv58rAzKETQu6trozz8psd2Rgo/LwQdT5qvUdU3Jc 06A0Zd8IeN0mcUjG27dGjtMJmPAOolmyB5ItGXiQ/s2Jq4XGYhFj/uL9J7ZhexrOZc 4PfBOjhdAroxOhKmVI/21kY7P64yVlJkHGrnDo4Ecp0nJ8F+dw3tE4eAue8LPvYNVN T6qVL5KSkF2GA== Date: Sat, 17 Feb 2024 10:39:19 +0000 To: Mark Millard From: Ordinary Bit Cc: Ronald Klop , "freebsd-arm@freebsd.org" Subject: Re: newfs TRIM flag device support Message-ID: In-Reply-To: <59693EE7-0DD6-4B41-BA64-0F3D69D3ECC9@yahoo.com> References: <6AD380D4-9B42-4511-9E02-94EB0005D278@yahoo.com> <8D8AA3F5-74A3-4AFE-A560-F52C7C55CF12@yahoo.com> <7okx4eDPse2uF1n3aX4W8RIOdbHXziUhqgvHxqqxpYN-7NsJfEGrfHbDxLgNS3PdOwZt7j9aOXp-0MHDjQAryL4t1Gd2QHUG1sFNmd5dY0k=@proton.me> <454941689.1180.1708079489598@localhost> <59693EE7-0DD6-4B41-BA64-0F3D69D3ECC9@yahoo.com> Feedback-ID: 100108111:user:proton List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4TcQKQ4krNz42RW X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH] > >=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