From nobody Sat Feb 17 03:29:01 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 4TcDms4jhGz5BZ0q for ; Sat, 17 Feb 2024 03:29:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-21.consmr.mail.gq1.yahoo.com (sonic305-21.consmr.mail.gq1.yahoo.com [98.137.64.84]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TcDms19Hyz4CTD for ; Sat, 17 Feb 2024 03:29:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1708140555; bh=rf11xTSAjJQpgTfboyp0FTYB38x8+YTkBQOTzTHsc4Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=HtlfcBjKgqOuohZUi6RG07ATCehBf6ZoZ3yXBO5OKWbxbCO2qT935HeJNcaYdTHmNT579NBgPqIWocJtZ+inQvbuN0VifipYJ17XFiA0UCqPnebuy3A/4AF5b21WJliJGeUZaPqWwOdJ1ZnLO4VnwFnrVQuU4AwL5iqmJnth2mvyqZIvBMu9IoltLHCMqG7i2zfFrPnCCC1LeojHCrmGW1sfqx8sgdm563RosF/NOvj1i8p1TBEyXBxwWyQONOgMgy3pgRGqjXLxXZfExZSy71Vl81GT/KbcHKB9vL/viHU/kZxsSxaoe3I7eJgsVAuKfSV58iv96tCipHklzxUJiw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1708140555; bh=L97x82WBikIWuBLseQCabZ9rTl+gz6GcTZmDXrTmnDm=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cXRvFXalgPP+tlKH6xzdk4BZTTMEUaUYDnH1yP2zpvOphvLvq9F4L6JcEc6jIzWknteLpKSYPtlEQL/9RU+/6qokMw2+r/WI+D2pRUol5mbuoat9aL8RSmKHzUY1Ng3rAWIK0voMJyzvdzpmR8s4Veuq9SoE4fQMT2An0P+1TzUYic3lqZQt8qOSqg4x3bKClSTy+vXEOcagNiI3ZLadoLXutdfbabqsL3+PApI4s36j20TEH53sFL3QXLD+h5fHddpPg5/wb9IBCFDst3+IG01CAVZ0S/cKqAqj70SVTOE1XoaVcSmTuqHrnRbkSLkCU6zh/ohOQcwncqoZKqKrWw== X-YMail-OSG: fh3JMToVM1ma2BTLLbtMHeFeaO3m8_eDPkGUTy18tMqG2HSI4kTZYcmSGXdcddj T6X9xLSwtz4LZneqqUsiJX.oVvpj2OoIkYN1zU7fXVH3w9qptPiSOsZrxc2y1ZIp1AZYk_58cVq5 i8FStdAiJJvV6lIynrbalPWzLt75u5Mlp3YYOpWrYknjQAjI1_Bjg_8MQeh0AYpY1tmpN4wbUFXd _sTxP8pe0PXQj_8h283FU_Ad_8vRMDCFBoH07UOT3pepHKFmSYni9ix1pX5RO_cbDQ91jHfXcPTK F0JmM_fUmr2PqNAiIfLWbnYKzsvLmx3.3VPgS8hrx4Piairc6.iynK5m_eQu91.4JkHczzK_iFDB 7fTxTa52r9MkchF5WsFw_N8LgSr9EyTHipYpj79T3Aum0z4gW5yGQan6YpdYyBZexpw5LJuNoxbV CHJvZ4XoMiOwJhdKoubIroUsKH9qAspARa9uXwMtqGQSmAHSQ_CXSWm6.xThSoaeknP8jSqoJ.4V HXeRaQQFxVycmlUt98sazeTPkOFhvT5kDgLN2ay1w1fDCe2wR7xxWZCfKKvJ_Hv.1cTINF8GmVwY mVU0KQKmQL_9XmWqqofQap51DRvh5o01XhMR7_8wHWP9Hdsy77lpS6dj0W7tQo.0FJ2NQfPV43_d 55lusP7yaxkmjBZvWUEDEGFrIV1CA9SoQAKBbXalhORgMyobH1jLnBKy.lIVT1ZbfHtWt8XkvrZM QbXP7Dpx8.39JnvjLtffpReB0j2Rywz02DLpijm_1eHYlPVTKygfNG5Xv5stx_ubyAbKveaRtEsV 8tx2BsyiBJDq9B0lFg.EctJIAz5TGJezc7c5rdQQviyEAs34_JN3XiLNpWgPO6Z2J_wA8Br1c5WB QH6hHpvWzwrCgRDvgOkkCj1VBZAQxjBIi62iOxVG5TiGyMWBBIFuQuYNzehpu9kEsRwKdU2NKvbq wH0Ru02WMHIhnf0FKJoEtZDo8_IyZ2UwfA3YDBImv9XK7AAIYVZKZ5XFaKw97l.D2YCTjFLqe.NX tZNNgT842zdEQmX_AblTRlq6ylx95nexPv1d6R2ZczhkNTXiGM8FBy6PciSHdFdILFun8eqkvqJ3 nWAbe2iM_L9gBbdpqSiUTv2koWvz6pdEJFkBxm5Dy60yLhH3EMIIlPedG6bVC8P5cSB6g1cKYuDc B0ZY.sWnAPn71rQ7by30CQp8uT.llxaTd0RJ_t_9FWwz6HIyhIwuqpPWL62zQ5KExp0_bsQFbX2B Zs0fACBj2..ne0ELJp5JUbiz7.cVpEYH92I34PhRgAZqfsw8VgvWudrf6czROGbcoOxZSxMtxo4x KAEe4Q66AF2MwR6U_O08ZRUD484.4RGWuUb_5M91DrlNLWzViTsMn2bx0cXYuWkeCODUCkEi6KeS RxJSvGbA1.MhPVAvZj85InKf4jmLGp.KN576cMD_JE6MPlN7_oNJ4VHYuiSjGgGgDNCNVxu5Jfd0 vhn3IVNevXciuRcJbcHw0DKOoZVUgLWVNEStqu942FpCXiMB3LlNRnbH5bPjbr.1z.XdJ07ZaZtP s0y.2zSsPVv2VPJ4fS2owpgWQCvFG_THpwhkEwIoHZvrm9JLPqUQXQ07QquFYeEO3qhywcA4pdqd O0I89zFqLNepp8Z_wplgYROGq6.DHXHGgmct5naMhqqx1xf1BtBh.wxysbqYZoIuk_nSgMqGaZb9 giFTChEaqmAr_xtGuDAAKpMpagLAejxu8G9SPptTaCXwlp0BshRLCe7v1GbZxZReYtIkj0c3fM5u zShPaV2ARum6LXNN63gJluZrsIZZDN4gU6fXXXF_cfZ.THh8yVYYYsiykSWB6q_i3MxuBFoESBDh Q8prfv.zOrByY6JiQU2uVa1wVW9VKqLoYB_gKXxgLkk5CMb9_mjAwOfwxLLKiGQl7RBapWlXWQsA ojSUI8PKic87GHacT..AFeJmWg81dV525K881USx_OjPj.IVnnUvGtSq0EN_P_Yz_yzuPQZSi0TI KykQr8HZoTZHUBZRJim8lj08qmOcMBzL9krTTeUMQXUCc1cGl6UFXoh0exQ1R0No4x3SY8aQDe55 lKVCjbOJoiM4r6N081.dMUrKgCly0z9ohWFJsPCYsag0a4xfpKxhAE1nVDiu4bdJ2z3TGrhqcri2 Aru5qoA.GR.2hh3bvt9xrYS_floyV4lpPWAR5Soxm8S3zZB7zLSuh9PsaAJ49dkXqBOpxQbASRM_ s2UOb1ifwMSRxYBLaFwsy9btKp009qU9qHN40A9huIM_EmZLm8YEEs19Lak8Umxy5E6fuy0Zx7i1 H X-Sonic-MF: X-Sonic-ID: 32dd325e-51d4-4e6f-8c20-4d2c693eb915 Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.gq1.yahoo.com with HTTP; Sat, 17 Feb 2024 03:29:15 +0000 Received: by hermes--production-gq1-5c57879fdf-wt62k (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 16c431e614640dbc0d9209c3a9dd5c09; Sat, 17 Feb 2024 03:29:12 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: newfs TRIM flag device support From: Mark Millard In-Reply-To: Date: Fri, 16 Feb 2024 19:29:01 -0800 Cc: Ronald Klop , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <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> To: Ordinary Bit X-Mailer: Apple Mail (2.3774.400.31) X-Spamd-Bar: ---- X-Rspamd-Queue-Id: 4TcDms19Hyz4CTD 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:36647, ipnet:98.137.64.0/20, country:US] On Feb 16, 2024, at 18:40, Ordinary Bit wrote: >=20 > On Friday, 16 February 2024 at 18:54, Ordinary Bit = wrote: >>=20 >>=20 >> On Friday, 16 February 2024 at 18:31, Ronald Klop = wrote: >>>=20 >>>=20 >>>=20 >>> Van: Ordinary Bit >>> Datum: vrijdag, 16 februari 2024 10:18 >>> Aan: Mark Millard >>> CC: "freebsd-arm@freebsd.org" >>> Onderwerp: Re: newfs TRIM flag device support >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Sent with Proton Mail secure email. >>>=20 >>> On Friday, 16 February 2024 at 14:02, Mark Millard = wrote: >>>=20 >>> > On Feb 15, 2024, at 20:08, Ordinary Bit ordinarybit@proton.me = wrote: >>> > >>> > > Hi! >>> > >>> > >>> > Hello. >>> > >>> > > On Friday, 16 February 2024 at 11:41, Mark Millard = marklmi@yahoo.com wrote: >>> > > >>> > > > [Only replying to lists I subscribe to.] >>> > > > >>> > > > On Feb 15, 2024, at 19:19, Ordinary Bit ordinarybit@proton.me = wrote: >>> > > > >>> > > > > I'm reading the newfs manual = https://man.freebsd.org/cgi/man.cgi?newfs(8) to be able to know about = the TRIM flag. In the manual under -t parameter, it mentioned about = "underlying device support", what exactly is this device? >>> > > > >>> > > > 2 contrasting examples: >>> > > > >>> > > > Example 0: Optane NVMe media (PCIe card or U.2, for example) >>> > > > >>> > > > Optane has no need of TRIM and, so, never supports TRIM. >>> > > > >>> > > > Example 1: microsd card media usage >>> > > > >>> > > > A microsd card in the normal type of microsd card slot on >>> > > > Small Board Computers (normally) supports TRIM. Take the >>> > > > same card and put it in a USB reader/writer and use it >>> > > > via USB on the same system: no TRIM is supported by >>> > > > FreeBSD over USB. >>> > > >>> > > So you mean to say that if I have a Rasperry Pi 3 or 4 now and = then have my FreeBSD installed in a microSD card (for example, SanDisk = Extreme card) with UFS/FFS filesytem in it with TRIM enabled parameter = then is it going to recognize it? How to verify? >>> > > >>> > > > FYI: >>> > > > >>> > > > When the file system has TRIM enabled, FreeBSD put out a >>> > > > notice if TRIM will not actually be used in the actual >>> > > > context in use. >>> > > >>> > > Ok, got it. How to check this as well? >>> > >>> > >>> > The console gets a message like: >>> > >>> > WARNING: /mnt: TRIM flag on fs but disk does not support TRIM >>> > >>> > when a mount is attempted (automatic or manually) for a >>> > file system with the trim flag enabled but trim does not >>> > end up active. >>> > >>> > So, for example: >>> > >>> > # dmesg -a | grep TRIM >>> > WARNING: /mnt: TRIM flag on fs but disk does not support TRIM >>> > >>> > (This was a microsd card in a USB reader/writer that was not >>> > used as the boot media: a separate manual mount was used.) >>> > >>> > The file system's TRIM flag status can be checked via use of >>> > "tunefs -p . . .": >>> > >>> > # tunefs -p /mnt >>> > tunefs: POSIX.1e ACLs: (-a) disabled >>> > tunefs: NFSv4 ACLs: (-N) disabled >>> > tunefs: MAC multilabel: (-l) disabled >>> > tunefs: soft updates: (-n) enabled >>> > tunefs: soft update journaling: (-j) disabled >>> > tunefs: gjournal: (-J) disabled >>> > tunefs: trim: (-t) enabled >>> > tunefs: maximum blocks per file in a cylinder group: (-e) 4096 >>> > tunefs: average file size: (-f) 16384 >>> > tunefs: average number of files in a directory: (-s) 64 >>> > tunefs: minimum percentage of free space: (-m) 8% >>> > tunefs: space to hold for metadata blocks: (-k) 6400 >>> > tunefs: optimization preference: (-o) time >>> > tunefs: volume label: (-L) >>> > >>> > If the trim flag is enabled but the mount does not produce the >>> > console message, then TRIM is active. >>> > >>>=20 >>> Oh, that's amazing! I try it with my SanDisk Ultra microSDXC 64GB = and mount it in a USB reader and it shows enabled in the tunefs and is = detected in the dmesg, the same as yours. Therefore, SanDisk Ultra = microSD supports it! >>>=20 >>> root@sd-extreme:~ # /sbin/newfs -U -t /dev/da0s2a >>> /dev/da0s2a: 59000.9MB (120833920 sectors) block size 32768, = fragment size 4096 >>> using 95 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, = 10243776, 11524224, 12804672, 14085120, >>> 15365568, 16646016, 17926464, 19206912, 20487360, 21767808, = 23048256, 24328704, 25609152, 26889600, 28170048, >>> 29450496, 30730944, 32011392, 33291840, 34572288, 35852736, = 37133184, 38413632, 39694080, 40974528, 42254976, >>> 43535424, 44815872, 46096320, 47376768, 48657216, 49937664, = 51218112, 52498560, 53779008, 55059456, 56339904, >>> 57620352, 58900800, 60181248, 61461696, 62742144, 64022592, = 65303040, 66583488, 67863936, 69144384, 70424832, >>> 71705280, 72985728, 74266176, 75546624, 76827072, 78107520, = 79387968, 80668416, 81948864, 83229312, 84509760, >>> 85790208, 87070656, 88351104, 89631552, 90912000, 92192448, = 93472896, 94753344, 96033792, 97314240, 98594688, >>> 99875136, 101155584, 102436032, 103716480, 104996928, 106277376, = 107557824, 108838272, 110118720, 111399168, >>> 112679616, 113960064, 115240512, 116520960, 117801408, 119081856, = 120362304 >>>=20 >>> root@sd-extreme:~ # dmesg | grep TRIM >>> WARNING: /mnt: TRIM flag on fs but disk does not support TRIM >>>=20 >>> root@sd-extreme:~ # tunefs -p /mnt >>> tunefs: POSIX.1e ACLs: (-a) disabled >>> tunefs: NFSv4 ACLs: (-N) disabled >>> tunefs: MAC multilabel: (-l) disabled >>> tunefs: soft updates: (-n) enabled >>> tunefs: soft update journaling: (-j) disabled >>> tunefs: gjournal: (-J) disabled >>> tunefs: trim: (-t) enabled >>> tunefs: maximum blocks per file in a cylinder group: (-e) 4096 >>> tunefs: average file size: (-f) 16384 >>> tunefs: average number of files in a directory: (-s) 64 >>> tunefs: minimum percentage of free space: (-m) 8% >>> tunefs: space to hold for metadata blocks: (-k) 6400 >>> tunefs: optimization preference: (-o) time >>> tunefs: volume label: (-L) >>>=20 >>> I plan to have TRIM flag enabled in the rootfs partition = (/dev/ufs/rootfs) of my Raspberry Pi. Do you think of any implications = when enabled? As shown below, it is disabled. >>>=20 >>> root@sd-extreme:~ # tunefs -p /dev/ufs/rootfs >>> tunefs: POSIX.1e ACLs: (-a) disabled >>> tunefs: NFSv4 ACLs: (-N) disabled >>> tunefs: MAC multilabel: (-l) disabled >>> tunefs: soft updates: (-n) enabled >>> tunefs: soft update journaling: (-j) disabled >>> tunefs: gjournal: (-J) disabled >>> tunefs: trim: (-t) disabled >>> tunefs: maximum blocks per file in a cylinder group: (-e) 4096 >>> tunefs: average file size: (-f) 16384 >>> tunefs: average number of files in a directory: (-s) 64 >>> tunefs: minimum percentage of free space: (-m) 8% >>> tunefs: space to hold for metadata blocks: (-k) 6400 >>> tunefs: optimization preference: (-o) time >>> tunefs: volume label: (-L) rootfs >>>=20 >>> BR, >>> orbit >>> =20 >>>=20 >>>=20 >>> =20 >>> Hi, >>>=20 >>> I'm sorry to spoil the fun but this message says the device does = *not* support trim. >>>=20 >>> "root@sd-extreme:~ # dmesg | grep TRIM >>> WARNING: /mnt: TRIM flag on fs but disk does not support TRIM" >>>=20 >>>=20 >>> But to give some hope. As Mark pointed out it is not only about the = disk. The controller also needs to support it. >>>=20 >>> As a real world example: >>>=20 >>> I have an RPI3 with an SSD (supporting trim) connected via = USB-to-SATA (not supporting trim). So the total system does not support = trim. >>> $ cat /var/run/dmesg.boot | grep -E "umass0|da0|TRIM" >>> umass0 on uhub1 >>> umass0: on usbus1 >>> umass0: SCSI over Bulk-Only; quirks =3D 0x0100 >>> umass0:0:0: Attached to scbus0 >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI device >>> da0: Serial Number 2015100000D6 >>> da0: 40.000MB/s transfers >>> da0: 244198MB (500118192 512 byte sectors) >>> da0: quirks=3D0x2 >>> WARNING: /: TRIM flag on fs but disk does not support TRIM >>>=20 >>> $ sysctl kern.cam.da.0 | grep -E "trim|delete" >>> kern.cam.da.0.trim_ticks: 0 >>> kern.cam.da.0.trim_goal: 0 >>> kern.cam.da.0.trim_lbas: 0 >>> kern.cam.da.0.trim_ranges: 0 >>> kern.cam.da.0.trim_count: 0 >>> kern.cam.da.0.delete_max: 65536 >>> kern.cam.da.0.delete_method: NONE >>>=20 >>>=20 >>> On an RPI4B I have an SSD (supporting trim) connected via = USB-to-SATA (which does support trim also). Here trim works fine. (NB: = this uses ZFS, but that does not matter) >>> $ dmesg | grep -E "umass0|da0" >>> umass0 on uhub0 >>> umass0: on usbus0 >>> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 >>> da0: Fixed Direct Access SPC-4 SCSI = device >>> da0: Serial Number 000000004BA8 >>> da0: 400.000MB/s transfers >>> da0: 244198MB (500118192 512 byte sectors) >>> da0: quirks=3D0x2 >>>=20 >>> $ sysctl kern.cam.da.0 | grep -E "trim|delete" >>> kern.cam.da.0.trim_ticks: 0 >>> kern.cam.da.0.trim_goal: 0 >>> kern.cam.da.0.trim_lbas: 546841704 >>> kern.cam.da.0.trim_ranges: 317280 >>> kern.cam.da.0.trim_count: 301424 >>> kern.cam.da.0.delete_max: 4294901760 >>> kern.cam.da.0.delete_method: UNMAP >>>=20 >>>=20 >>> BTW: enabling trim on the fs while the device does not support it = does not matter and does no harm. Using the sysctl above you can see if = the device actually uses trim. >>>=20 >>> Running "gstat -d" while deleting a lot of files will also show if = trim/delete actions are sent to the disk. >>>=20 >>> So the combination of your USB reader + microSD do not support TRIM, = but you can just try to put the microSD directly in the RPI4 and see = what that does. >>>=20 >>> Regards, >>> Ronald. >>=20 >> Thanks for the callout! Got warmed-up when I saw the TRIM is enabled = :-) but my ultimate goal is really the microSD card slot of my Raspberry = Pi 3 or 4 and not with the USB reader. I'll create an image then see how = it does. >>=20 >> BR, >> orbit=20 >=20 > 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. 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 ? 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. 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. 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 /dev/da0 is not the microsd card slot, but a USB device. > root@sd-extreme:~ # gpart show The result would be easier to track with # gpart show -p That would show notation that could be used after /dev/ instead of index numbers. > =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) There is no /dev/mmcsd0s3 above. > =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) There is a /dev/da0s3 already existing above. But it is not (yet) freebsd-ufs. > =3D> 0 10381312 da0s2 BSD (5.0G) > 0 128 - free - (64K) > 128 10381184 1 freebsd-ufs (4.9G) That freebsd-ufs is /dev/da0s2a . > =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 /dev/da0s3 is not in the microsd card slot, but on a USB device. > /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, = 10243776, 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) Looks like you moved the microsd card to the microsd card slot from the usb device? > 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 When did you create and delete the files? > dT: 1.065s w: 1.000s During that 1.065s interval? > 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 = 1264 ) > 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 = 7866, reads: sync 121491 async 0, fsid 4ee0c86506330890, vnodes: count 3 = ) >=20 > root@sd-ultra:~ # sysctl -a | grep trim # sysctl -a | grep -i trim ? (TRIM is sometimes in capitals.) # dmesg -a | grep -i trim ? > <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 = grade card. Either TRIM will work or not there's still garbage = collection I could benefit. It looks to me like the testing procedure may have been flawed. =3D=3D=3D Mark Millard marklmi at yahoo.com