https://man.freebsd.org/cgi/man.cgi?query=mdmfs&sektion=8&apropos=0&manpath=FreeBSD+14.0-RELEASE+and+Ports Say: > Create and mount a 16 megabyte malloc-backed file system on /tmp using > the /dev/md1 device; furthermore, do not use soft-updates on it and > mount it async: > > mdmfs -M -S -o async -s 16m md1 /tmp But soft updates enabled and no "async". # mdmfs -M -S -o async -s 16m md1 /media # mount /dev/md1 on /media (ufs, local, soft-updates) # tunefs -p /dev/md1 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) 40 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) # mount -v /dev/md1 on /media (ufs, local, soft-updates, writes: sync 2 async 0, reads: sync 3 async 0, fsid 1572526616e23f74, vnodes: count 2 ) # uname -a FreeBSD rimwksv 14.1-STABLE FreeBSD 14.1-STABLE RIM_WKS amd64 Also, IMHO, -t should be forced for all memory backend mount points.
I discovered this independently today on my 14.1p3 system and can confirm this also affects FreeBSD 14.1 and the upcoming 13.4 (confirmed on RC1 image) AMD64 editions when testing from the Live mode of the disc1 CD installer image: FreeBSD-14.1-RELEASE-amd64-disc1.iso: root@:~ # uname -a FreeBSD 14.1-RELEASE FreeBSD 14.1-RELEASE releng/14.1-n267679-10e31f0946d8 GENERIC amd64 root@:~ # mdmfs -M -S -o async -s 16m md1 /mnt root@:~ # mount /dev/md1 on /mnt (ufs, local, soft-updates) root@:~ # tunefs -p /dev/md1 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) 40 tunefs: optimization preference: (-o) time tunefs: volume label: (-L) FreeBSD-13.4-RC1-amd64-disc1.iso: root@:~ # uname -a FreeBSD 13.4-RC1 FreeBSD 13.4-RC1 releng/13.4-n258234-700ff8f05f08 GENERIC amd64 root@:~ # mdmfs -M -S -o async -s 16m md1 /mnt root@:~ # mount /dev/md1 on /mnt (ufs, local, soft-updates) root@:~ # tunefs -p /dev/md1 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) 40 tunefs: optimization preference: (-o) time tunefs: volume label: (-L)
I'm guessing bug has been in place since the defaults for newfs were changed to enable soft-updates by default, based on what I see in mdmfs.c: if (softdep) argappend(&newfs_arg, "-U"); Not quite sure what the specific fix would be here as newfs doesn't have a flag to disable soft-updates when formatting a filesystem, outside of "tunefs -n disable" being run.
Just one more note here that when specifying UFS1 as the filesystem to mdmfs (-v 1) it does work as expected: # mdmfs -v 1 -M -S -o async -s 16m md1 /mnt # mount /dev/md1 on /mnt (ufs, asynchronous, local) # tunefs -p /dev/md1 tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) disabled 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) 40 tunefs: optimization preference: (-o) time tunefs: volume label: (-L)
Looks like this is fallout from 61dece6d27fb2436928ca93d65667b358e05aa7b -- the newfs default was changed (softupdates turned on by default) but the code in mdmfs which runs newfs wasn't updated.
Created attachment 253136 [details] Proposed fix to mdmfs(8) See proposed fix to mdmfs(8).
Applied the patch to 14.1p4, issue resolved: # ./mdmfs -M -S -o async -s 16m md1 /media # mount -v /dev/md1 on /media (ufs, asynchronous, local, writes: sync 2 async 0, reads: sync 3 async 0, fsid 033fda663af4f405, vnodes: count 2 ) # tunefs -p /dev/md1 tunefs: POSIX.1e ACLs: (-a) disabled tunefs: NFSv4 ACLs: (-N) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) disabled 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) 40 tunefs: optimization preference: (-o) time tunefs: volume label: (-L)
Any chance of this being committed before the upcoming 14.2 release? From my testing the patch resolves the reported issue.
Yes we should get this into 14.2, thanks for the reminder. Kirk, can you commit this?
What about TRIM? If TRIM is off for memory backed FS than all vnodes from removed files keep in memory for a while. Is is almost memleak.
(In reply to Ivan Rozhuk from comment #9) While I agree that it does makes sense to have TRIM enabled by default, is there any specific reason not to use tmpfs (which will avoid the file system -> memory disk indirection) for these filesystems?
(In reply to Xin LI from comment #10) tmpfs is much faster than md, but while compiling something like chromium on desktop with md it freezes less that with tmpfs. "nomtime,pgread" makes tmpfs a better but still have freezes in apps. I has try: 1. set lowest possible prio to build process: /usr/sbin/idprio 31 /usr/bin/nice -n 20 /usr/bin/make https://github.com/rozhuk-im/freebsd-ports/commit/0f9892b7bf8ea92be02123a5b75269b5877f1216 2. set highest possible for Xorg: xserver-command=/usr/sbin/rtprio 0 /usr/bin/nice -n -20 /usr/bin/env MESA_SHADER_CACHE_DISABLE='true' /usr/local/bin/X 3. avoid caching in /tmp graphics related things: MESA_SHADER_CACHE_DISABLE='true' 4. reduce mmap()/unmap() usage by malloc: malloc.conf@ -> metadata_thp:disabled,retain:true,dss:disabled,narenas:8,background_thread:false,tcache:true,lg_tcache_max:16 5. play with memory disk and options It is still poor user experience while chromium build in progress, but a better that without this steps. I do suspect that is it some memory fragmentation problem that reduce mmap() performance + amdgpu lags than freemem is at minimum level so pagedaemon pump mem for amdgu from laudary and other staff with delay.
(In reply to Xin LI from comment #10) Not opining on the TRIM-as-default situation, but in regards to using md disks over tmpfs I have one that I use regularly-- remote root-FS maintenance. I can use a memory-backed md disk with "reboot -r" to ensure continuity of a memory disk while rerooting a system. ** connect to a host via ssh mdmfs -s 16g md /mnt ** creates a 16g disk as /dev/md0 cd /mnt dump -0Laf - / | restore rf - umount /dev/md0 kenv vfs.root.mountfrom="ufs:/dev/md0" reboot -r ** reconnect to the host via ssh Now I can do maintenance on the root-FS on the host remotely. This won't work with tmpfs as the file system disappears as soon as it is unmounted.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5b21d4ad060acb06c72e0458daebec9bcbf0cefd commit 5b21d4ad060acb06c72e0458daebec9bcbf0cefd Author: Kirk McKusick <mckusick@FreeBSD.org> AuthorDate: 2024-10-03 15:05:42 +0000 Commit: Kirk McKusick <mckusick@FreeBSD.org> CommitDate: 2024-10-03 15:06:28 +0000 Ensure that soft updates are not enabled by default when using mdmfs(8) When soft updates began being enabled by default that change carried over to mdmfs(8) which does not want or need them. This fix ensures that they are only enabled in mdmfs(8) when requested with the -U flag. Reported by: Ivan Rozhuk Tested by: Ivan Rozhuk PR: 279308 MFC after: 1 week include/paths.h | 3 +++ sbin/mdmfs/mdmfs.c | 9 ++++++++- 2 files changed, 11 insertions(+), 1 deletion(-)
(In reply to Colin Percival from comment #8) Now committed. Sorry for the delay. I am on a river-boat on the Nile with really minimal Internet connectivity. Will MFC to 14 in a week.
(In reply to Ivan Rozhuk from comment #9) This bug report is about not enabling soft-updates by default. If you want to have a discussion about adding TRIM by default that should be in a new phabricator review or a new bug report.
(In reply to Kirk McKusick from comment #14) Thanks! Yeah I knew you were AFK so I wasn't too worried about the delay.
Thank you Kirk and Colin for squashing this, it is much appreciated here!
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=54416c6e137980197ee7a3cdc124174642f32af2 commit 54416c6e137980197ee7a3cdc124174642f32af2 Author: Kirk McKusick <mckusick@FreeBSD.org> AuthorDate: 2024-10-03 15:05:42 +0000 Commit: Kirk McKusick <mckusick@FreeBSD.org> CommitDate: 2024-10-12 22:30:06 +0000 Ensure that soft updates are not enabled by default when using mdmfs(8) When soft updates began being enabled by default that change carried over to mdmfs(8) which does not want or need them. This fix ensures that they are only enabled in mdmfs(8) when requested with the -U flag. Reported by: Ivan Rozhuk Tested by: Michael Proto PR: 279308 (cherry picked from commit 5b21d4ad060acb06c72e0458daebec9bcbf0cefd) include/paths.h | 3 +++ sbin/mdmfs/mdmfs.c | 9 ++++++++- 2 files changed, 11 insertions(+), 1 deletion(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=51b1d399b2de88695030a23430fd6bd9cfb15293 commit 51b1d399b2de88695030a23430fd6bd9cfb15293 Author: Kirk McKusick <mckusick@FreeBSD.org> AuthorDate: 2024-10-03 15:05:42 +0000 Commit: Kirk McKusick <mckusick@FreeBSD.org> CommitDate: 2024-10-12 22:33:05 +0000 Ensure that soft updates are not enabled by default when using mdmfs(8) When soft updates began being enabled by default that change carried over to mdmfs(8) which does not want or need them. This fix ensures that they are only enabled in mdmfs(8) when requested with the -U flag. Reported by: Ivan Rozhuk Tested by: Michael Proto PR: 279308 (cherry picked from commit 5b21d4ad060acb06c72e0458daebec9bcbf0cefd) include/paths.h | 3 +++ sbin/mdmfs/mdmfs.c | 9 ++++++++- 2 files changed, 11 insertions(+), 1 deletion(-)
Fix has been MFC'ed to 13 and 14.