Verified on FreeBSD 13.2, but it happens also on freebsd 15.0-CURRENT: makefs command executed without parameters creates a UFS clean fs as expected, but if size option is used the fs is corrupt. A simplified test: root@freebsd:~ # uname -a FreeBSD freebsd 13.2-RELEASE-p3 FreeBSD 13.2-RELEASE-p3 GENERIC amd64 E.g. I use the content of /usr/bin to fill out the new fs with makefs: root@freebsd:~ # du -hs /usr/bin/ 328M /usr/bin/ Without the -s option the fs is good: # makefs ./image1 /usr/bin Calculated size of `./image1': 400621568 bytes, 368 inodes Extent size set to 32768 ./image1: 382.1MB (782464 sectors) block size 32768, fragment size 4096 using 1 cylinder groups of 382.06MB, 12226 blks, 512 inodes. super-block backups (for fsck -b #) at: 64, Populating `./image1' Image `./image1' complete root@freebsd:/makefs_test # mdconfig -a -t vnode -f ./image1 md0 root@freebsd:/makefs_test # fsck /dev/md0 ** /dev/md0 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 367 files, 83999 used, 13768 free (40 frags, 1716 blocks, 0.0% fragmentation) ***** FILE SYSTEM IS CLEAN ***** root@freebsd:/makefs_test # mount /dev/md0 /mnt root@freebsd:/makefs_test # du -hs /mnt 328M /mnt If any size is specified, the created fs is corrupt: root@freebsd:/makefs_test # makefs -s 600m ./image2 /usr/bin Calculated size of `./image2': 629145600 bytes, 368 inodes Extent size set to 32768 density reduced from 1709635 to 8192 ./image2: 600.0MB (1228800 sectors) block size 32768, fragment size 4096 using 1 cylinder groups of 600.00MB, 19200 blks, 76800 inodes. super-block backups (for fsck -b #) at: 64, Populating `./image2' Image `./image2' complete root@freebsd:/makefs_test # mdconfig -a -t vnode -f ./image2 md1 root@freebsd:/makefs_test # fsck /dev/md1 ** /dev/md1 ** Last Mounted on ** Phase 1 - Check Blocks and Sizes UFS1 cylinder group 0 failed: cgp->cg_old_niblk ("11264") != sblock.fs_ipg ("76800") CYLINDER GROUP 0: INTEGRITY CHECK FAILED REBUILD CYLINDER GROUP? [yn] y ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups SUMMARY INFORMATION BAD SALVAGE? [yn] y BLK(S) MISSING IN BIT MAPS SALVAGE? [yn] y 367 files, 83999 used, 67176 free (40 frags, 8392 blocks, 0.0% fragmentation) ***** FILE SYSTEM IS CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** The fs is not repaired despite repeated fsck and the 'clean' final status: root@freebsd:/makefs_test # fsck -y /dev/md1 ** /dev/md1 ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes UFS1 cylinder group 0 failed: cgp->cg_old_niblk ("11264") != sblock.fs_ipg ("76800") CYLINDER GROUP 0: INTEGRITY CHECK FAILED REBUILD CYLINDER GROUP? yes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups SUMMARY INFORMATION BAD SALVAGE? yes BLK(S) MISSING IN BIT MAPS SALVAGE? yes 367 files, 83999 used, 67176 free (40 frags, 8392 blocks, 0.0% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** ***** FILE SYSTEM WAS MODIFIED ***** Thank you!
The image isn't corrupt. It's perfectly readable. Only the summary information is incorrect, which is just metadata that fsck reconstructs. It is a problem that needs to be fixed, but isn't an image with bad data user data.
Also, you should be able to fsck the image directly w/o needing the md device.
I'll take a look at this, as it potentially affects the boot loader automation we're doing.
Thanks for the information. This makes sense: the systems used these fs (mounted in RO) without issues for a while.I noticed the issue only during a random check (the "preen" fsck at boot time is always clean). Now I found a temporary workaround creating the fs with some additional options ("-o bsize=4096 -o density=8192"), but I'll remove them when the fix will be available. Thanks again!
Bug #277739 is similar except fsck wants to clear an inode while rebuilding a cylinder group.
^Triage: committer's bit was taken in for safekeeping.
^Triage: reassign by request. It turns out only the ports bit was taken into safekeeping, not the src bit.
^Triage: is there anything further to do on this PR?
(In reply to Mark Linimon from comment #8) Well clearly we need to commit a fix. I was sure I saw a patch fly by a couple of days ago, but it doesn't seem to have made it into the log. I'm going to have to look for it.
I spoke with Kirk about this some time ago. The root cause of this problem is that makefs was ported from NetBSD, and it doesn't have all the latest changes Kirk has done to FreeBSD. To fix this, we'd need to redo the ufs filesystem creation code from that base. This isn't just a simple fix, and nobody has signed up to do the heavy lift needed.
When makefs builds UFS filesystems by defaulk it is using UFS1 (which we stopped doing two decades ago). Further it is at least a decade out of date having none of the modern reliability improvements such as superblock and inode checksums. It also is still using layout styles that are at least a decade out of date. It appears to be using NetBSD's ufs filesystem. Rather than trying to bring all that code up to date, it should just fork off a mkfs to build the filesystem as in that way it will keep up with ongoing work to harden and improve UFS. It would require minimal work to adapt mkfs to writing a disk image to a file rather than to a disk partition.
See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277739