Re: newfs TRIM flag device support

Sent with Proton Mail secure email.

On Sunday, 18 February 2024 at 19:09, Ordinary Bit <[email protected]> wrote:

> On Sunday, 18 February 2024 at 03:04, Mark Millard [email protected] wrote:
> 
> > On Feb 17, 2024, at 08:44, Mike Karels [email protected] wrote:
> > 
> > > On 17 Feb 2024, at 10:21, Ordinary Bit wrote:
> > > 
> > > > On Saturday, 17 February 2024 at 23:20, Mark Millard [email protected] wrote:
> > > > 
> > > > > On Feb 17, 2024, at 02:39, Ordinary Bit [email protected] wrote:
> > > > > . . .
> > > > > 
> > > > > > 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.
> > > > 
> > > > Let me test this one with freebsd-ufs type because you're right it's only 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)
> > > > > > 
> > > > > > => 0 10381312 mmcsd0s2 BSD (5.0G)
> > > > > > 0 128 - free - (64K)
> > > > > > 128 10381184 mmcsd0s2a freebsd-ufs (4.9G)
> > > > > > . . .
> > 
> > My splitting of the gpart output at the line I was interested in
> > may have left some confusion. So I'll quote the original full
> > output. I was not very explicit about the details of the oddities
> > involved before but will be so below.
> > 
> > QUOTE
> > 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)
> > 27262976 97472512 - free - (46G)
> > 
> > => 0 10381312 mmcsd0s2 BSD (5.0G)
> > 
> > 0 128 - free - (64K)
> > 128 10381184 mmcsd0s2a freebsd-ufs (4.9G)
> > END QUOTE
> > 
> > First note that mmcsd0s2a says freebsd-ufs (but is
> > inside a BSD). That is what I consider normal for MBR
> > partitions that contain UFS file systems.
> > 
> > Next note that there was no "mmcsd0s3 BSD" shown.
> > Nor was there a "mmcsd0s3a freebsd-ufs" shown.
> > "mmcsd0s3 freebsd" shows no evidence of any MBR/BSD
> > substructure. (But it was mountable as a UFS file
> > system after the newfs that was done on mmcsd0s3 .)
> > 
> > None of this messed up the testing that was being
> > done.
> 
> 
> Basically what I did after creating the mmcsd0s3 partition, I format it right away with newfs. So I re-created the setup to clear things out. This time having mmcsd0s3 partition and mmcsd0s3a in freebsd-ufs type. You can see below sequences of procedures. I deleted the existing mmcsd0s3 partition first and then create a new one in the same 8GB size.
> 
> root@sd-ultra:~ # /sbin/gpart delete -i 3 mmcsd0
> mmcsd0s3 deleted
> root@sd-ultra:~ # /sbin/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 114249728 - free - (54G)
> 
> => 0 10381312 mmcsd0s2 BSD (5.0G)
> 
> 0 128 - free - (64K)
> 128 10381184 mmcsd0s2a freebsd-ufs (4.9G)
> 
> root@sd-ultra:~ # /sbin/gpart add -t freebsd -s 8G mmcsd0
> mmcsd0s3 added
> root@sd-ultra:~ # /sbin/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)
> 27262976 97472512 - free - (46G)
> 
> => 0 10381312 mmcsd0s2 BSD (5.0G)
> 
> 0 128 - free - (64K)
> 128 10381184 mmcsd0s2a freebsd-ufs (4.9G)
> 
> => 0 16777216 mmcsd0s3 BSD (8.0G)
> 
> 0 16777216 mmcsd0s3a freebsd-ufs (8.0G)
> 
> => 0 16777216 ufsid/65c95062ec444331 BSD (8.0G)
> 
> 0 16777216 ufsid/65c95062ec444331a freebsd-ufs (8.0G)
> root@sd-ultra:~ #
> root@sd-ultra:~ # /sbin/newfs -U -t /dev/mmcsd0s3a
> /dev/mmcsd0s3a: 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
> root@sd-ultra:~ #
> root@sd-ultra:~ # /sbin/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)
> 27262976 97472512 - free - (46G)
> 
> => 0 10381312 mmcsd0s2 BSD (5.0G)
> 
> 0 128 - free - (64K)
> 128 10381184 mmcsd0s2a freebsd-ufs (4.9G)
> 
> => 0 16777216 mmcsd0s3 BSD (8.0G)
> 
> 0 16777216 mmcsd0s3a freebsd-ufs (8.0G)
> 
> => 0 16777216 ufsid/65c93f4a5cb247cf BSD (8.0G)
> 
> 0 16777216 ufsid/65c93f4a5cb247cfa freebsd-ufs (8.0G)
> root@sd-ultra:~ #
> root@sd-ultra:~ # mount /dev/mmcsd0s3a /mnt
> root@sd-ultra:~ #
> root@sd-ultra:~ # /sbin/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)
> 27262976 97472512 - free - (46G)
> 
> => 0 10381312 mmcsd0s2 BSD (5.0G)
> 
> 0 128 - free - (64K)
> 128 10381184 mmcsd0s2a freebsd-ufs (4.9G)
> 
> => 0 16777216 mmcsd0s3 BSD (8.0G)
> 
> 0 16777216 mmcsd0s3a freebsd-ufs (8.0G)
> 
> root@sd-ultra:~ # cp /home/freebsd/file01 /mnt/file01
> root@sd-ultra:~ # cd /mnt
> root@sd-ultra:/mnt #
> root@sd-ultra:/mnt # ls -lah
> total 1421036
> drwxr-xr-x 3 root wheel 512B Feb 11 21:44 .
> drwxr-xr-x 21 root wheel 512B Feb 11 20:04 ..
> drwxrwxr-x 2 root operator 512B Feb 11 21:42 .snap
> -rw-r--r-- 1 root wheel 1.4G Feb 11 21:47 file01
> root@sd-ultra:/mnt #
> root@sd-ultra:/mnt # cp file01 file02
> root@sd-ultra:/mnt # ls -lah
> total 2842060
> drwxr-xr-x 3 root wheel 512B Feb 11 22:01 .
> drwxr-xr-x 21 root wheel 512B Feb 11 20:04 ..
> drwxrwxr-x 2 root operator 512B Feb 11 21:42 .snap
> -rw-r--r-- 1 root wheel 1.4G Feb 11 21:47 file01
> -rw-r--r-- 1 root wheel 1.4G Feb 11 22:03 file02
> root@sd-ultra:/mnt #
> root@sd-ultra:/mnt # rm *
> root@sd-ultra:/mnt #
> 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
> 15 327 15 479 31.0 1 32 7.6 311 1242254 30.9 53.1| 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 33 15 479 31.0 1 32 7.6 17 1176886 53.3 50.9| 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
> 5 33 15 479 31.0 1 32 7.6 17 1176886 53.3 50.9| mmcsd0s3a
> 0 0 0 0 0.0 0 0 0.0 0 0 0.0 0.0| ufs/rootfs
> 
> The TRIM activity were observed the same as previous but having the mmcsd0s3a along with mmcsd0s3 and mmcsd0.
> 
> BR,
> orbit

Oh I see, with tunefs it's also possible to enable/disable TRIM flag. I just tried out the rootfs partition (/dev/da0s2a) enabled and it did. 

root@sd-ultra:~ # /sbin/tunefs -t enable /dev/da0s2a
tunefs: issue TRIM to the disk set

Thanks for this great tool!

BR,
orbit

 
>