Bug 273725 - makefs command creates UFS fs image with bad summary info when size option (-s) is specified
Summary: makefs command creates UFS fs image with bad summary info when size option (-...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 13.2-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: Greg Lehey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-11 17:50 UTC by Jane
Modified: 2024-03-16 21:17 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jane 2023-09-11 17:50:35 UTC
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!
Comment 1 Warner Losh freebsd_committer freebsd_triage 2023-09-11 18:35:35 UTC
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.
Comment 2 Warner Losh freebsd_committer freebsd_triage 2023-09-11 18:35:58 UTC
Also, you should be able to fsck the image directly w/o needing the md device.
Comment 3 Warner Losh freebsd_committer freebsd_triage 2023-09-11 18:36:29 UTC
I'll take a look at this, as it potentially affects the boot loader automation we're doing.
Comment 4 Jane 2023-09-13 09:22:18 UTC
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!
Comment 5 John F. Carr 2024-03-16 21:17:40 UTC
Bug #277739 is similar except fsck wants to clear an inode while rebuilding a cylinder group.