From nobody Sat Feb 17 16:44: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 4TcZQM6SgVz5BTY7 for ; Sat, 17 Feb 2024 16:44:27 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail2.karels.net (mail2.karels.net [3.19.118.201]) (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 (2048 bits) client-digest SHA256) (Client CN "freebsd", Issuer "freebsd" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TcZQM4NMrz4q1x for ; Sat, 17 Feb 2024 16:44:27 +0000 (UTC) (envelope-from mike@karels.net) Authentication-Results: mx1.freebsd.org; none Received: from mail2.karels.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by mail2.karels.net (8.17.1/8.17.1) with ESMTP id 41HGiK6q020439; Sat, 17 Feb 2024 10:44:20 -0600 (CST) (envelope-from mike@karels.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=karels.net; s=mail2; t=1708188261; bh=LBRgPI1ZylS/xjT4UII+zLHAZZPHMKbPdrfXP1o0XzI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ExnAUCIxJcEgkVSJChJCmimiikaRVLARmg6vrBFx7Zz3uoP/EA94un7jtA7wdSpCx 1ICFkNYaVmq+g0l45RmHYoziYVRjjVouqzBYcl6m+PXPJPYhpA5/msmpgaRzYpAoEY MlMqHSbsJI47Hw9+JxvAvicFtoYbP79e7S5oiwxcRQO0Jp99rrqjDATVhDkr+EaXPi qRNFv77xWrU5HfTK1QG/JCYsSxYwMb1c3ojkvi7OsiVQ6cD+SqjX9pDObnhjOI/Ow/ P3GuAv/vGP29RAqwsy8LLooDKnPSkJvQUkXGGgw22D7KIy9e5AMR7MxGOt1eSoQBTt 1ylcPCDzTxm5Q== Received: from [10.0.2.130] ([73.62.165.147]) by mail2.karels.net with ESMTPSA id 4ucFI2Ti0GXVTwAAs/W3XQ (envelope-from ); Sat, 17 Feb 2024 10:44:20 -0600 From: Mike Karels To: Ordinary Bit Cc: Mark Millard , Ronald Klop , freebsd-arm@freebsd.org Subject: Re: newfs TRIM flag device support Date: Sat, 17 Feb 2024 10:44:19 -0600 X-Mailer: MailMate (1.14r6015) Message-ID: In-Reply-To: References: <8D8AA3F5-74A3-4AFE-A560-F52C7C55CF12@yahoo.com> <7okx4eDPse2uF1n3aX4W8RIOdbHXziUhqgvHxqqxpYN-7NsJfEGrfHbDxLgNS3PdOwZt7j9aOXp-0MHDjQAryL4t1Gd2QHUG1sFNmd5dY0k=@proton.me> <454941689.1180.1708079489598@localhost> <59693EE7-0DD6-4B41-BA64-0F3D69D3ECC9@yahoo.com> <1B0C2E27-6776-40A1-A8BF-29094FF8FC03@yahoo.com> 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 Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4TcZQM4NMrz4q1x 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:16509, ipnet:3.16.0.0/14, country:US] On 17 Feb 2024, at 10:21, Ordinary Bit wrote: > On Saturday, 17 February 2024 at 23:20, Mark Millard 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