Re: newfs TRIM flag device support
- In reply to: Ordinary Bit : "Re: newfs TRIM flag device support"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 17 Feb 2024 15:42:35 UTC
On Saturday, 17 February 2024 at 18:39, Ordinary Bit <ordinarybit@proton.me> wrote:
> > > 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
> >
> > ?
>
>
> No, it didn't show up in the dmesg output after I mounted /dev/mmcsd03 on /mnt.
>
> 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)
>
> 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 async 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/mmcsd0s3
> 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 async 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, reads: sync 3 async 0, fsid 4ee0c86506330890, vnodes: count 2 )
>
> 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.
>
> > 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 replicating, 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 suddenly 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 never 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
>
> > 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.
> >
> > > => 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)
> > >
> > > => 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.
> >
> > > => 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.
> >
> > > => 0 10381312 da0s2 BSD (5.0G)
> > > 0 128 - free - (64K)
> > > 128 10381184 1 freebsd-ufs (4.9G)
> >
> > That freebsd-ufs is /dev/da0s2a .
> >
> > > => 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)
> > >
> > > => 0 10381312 diskid/DISK-121220160204s2 BSD (5.0G)
> > > 0 128 - free - (64K)
> > > 128 10381184 1 freebsd-ufs (4.9G)
> > >
> > > root@sd-extreme:~ # ls -lah /dev/da0
> > > /dev/da0 /dev/da0s1 /dev/da0s2 /dev/da0s2a /dev/da0s3
> > >
> > > 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
> > >
> > > root@sd-ultra:~ # gpart show -l
> > > => 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)
> > >
> > > => 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?
>
>
> 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 partition which is the /dev/da0s3 having UFS/FFS plus the TRIM flag enabled. I also 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. From here, I moved the microsSD card from @sd-extreme and insert it into my Raspberry Pi 4 microSD slot with hostname @sd-ultra. From here, partitions changed from /dev/da0* to /dev/mmcsd0*.
>
> > > 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)
> > >
> > > 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
> > >
> > > 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 )
> > >
> > > root@sd-ultra:~ # sysctl -a | grep trim
> >
> > # 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
>
> > > <118>Creating and/or trimming log files.
> > > kern.cam.nda.max_trim: 256
> > > vfs.ffs.dotrimcons: 1
> > >
> > > 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.
>
>
> Maybe but upon re-testing I already found this gstat deleting activity, 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 TRIM happened in your simulation?
>
> BR,
> orbit
By redoing what I've performed in Raspberry Pi 4B with the same SanDisk microSD card inserted in Raspberry Pi 3B, the delete activity were also observed in gstat.
root@sd-ultra:~ # mount /dev/mmcsd0s3 /mnt
root@sd-ultra:~ # mount -lv
/dev/ufs/rootfs on / (ufs, local, soft-updates, writes: sync 12 async 185, reads: sync 900 async 3, fsid 89fc4d652aba17cd, vnodes: count 504 )
devfs on /dev (devfs, fsid 00ff007171000000, vnodes: count 37 )
/dev/msdosfs/EFI on /boot/efi (msdosfs, local, noatime, writes: sync 1 async 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 21, reads: sync 65 async 0, fsid 4ee0c86506330890, vnodes: count 3 )
root@sd-ultra:~ # cd /mnt
root@sd-ultra:/mnt # ls -lah
total 5684108
drwxr-xr-x 3 root wheel 512B Feb 11 20:41 .
drwxr-xr-x 21 root wheel 512B Feb 11 20:55 ..
drwxrwxr-x 2 root operator 512B Feb 11 14:57 .snap
-rw-r--r-- 1 root wheel 1.4G Feb 11 20:35 file1
-rw-r--r-- 1 root wheel 1.4G Feb 11 20:38 file2
root@sd-ultra:/mnt # rm *
root@sd-ultra:~ # gstat -d
dT: 1.041s w: 1.000s
L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name
23 586 20 645 44.6 0 0 0.0 566 2229919 27.0 90.2| 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
3 59 20 645 44.6 0 0 0.0 38 2225985 49.6 90.1| 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
So, it's just a matter of waiting until it occurs.
BR,
orbit