FreeBSD-provided disk images: problems with UFS, fsck_ufs (fsck_ffs(8)); partition sizes …

[Cath O'Deray]

256746 – fsck_ffs completely broken for background fsck

bugs.freebsd.org

Proposed fix: ⚙ D30880 fsck_ufs: fix background fsck in preen mode

 

[Cath O'Deray]

The FreeBSD Project | Frequently Asked Questions for FreeBSD 11.X, 12.X, and 13.X

Section 8.3 seems to contradict (a) what's currently in the FreeBSD Handbook; and (b) real world test results.

Re: <https://cgit.freebsd.org/doc/tree/d...766aad81955ca8746248a67b3fa85148f0134ae#n1266> and thereabouts it will be good to have corrections, in due course; let's await the outcomes of bug reports …

 

[Alain De Vos]

256746 – fsck_ffs completely broken for background fsck

bugs.freebsd.org

Proposed fix: ⚙ D30880 fsck_ufs: fix background fsck in preen mode

That's a serious one.

 

[Cath O'Deray]

serious

True, however soft updates without soft updates journaling is probably an uncommon use case.

In parallel: it's possible for journaling to be apparently enabled – e.g. -j in output from dumpfs -m / – but non-effective.

dumpfs(8)

 

[Cath O'Deray]

UFS - gpart recover ada0 fails with FreeBSD-provided disk images grown to 2.00 TB

Steps: download (for example) FreeBSD-11.4-RELEASE-amd64.vhd.xz verify the checksum extract FreeBSD-11.4-RELEASE-amd64.vhd add the virtual disk to VirtualBox grow the disk to 2.00 TB create a machine to use the disk boot in single user mode gpart recover ada0 Expected: a good partition table...

forums.freebsd.org

 

[Cath O'Deray]

Where fsck repairs a file system and marks it clean: is there any situation in which it's normal for an immediately subsequent run of fsck to mark it dirty?

 

[ralphbsz]

If the file system has not been mounted or modified in between, then the second run should not mark it dirty. If the file system *IS* mounted during the time of the two fsck runs, things get very complicated; it's not easy to define what "clean" or "dirty" mean on a mounted file system.

 

[Cath O'Deray]

Thanks,

If the file system has not been mounted or modified in between,

It has not. The behaviour seems to be easily reproducible with FreeBSD 14.0-CURRENT d1a0eab9fbc <https://cgit.freebsd.org/src/log/?qt=range&q=d1a0eab9fbc>.

I can't tell whether it's reproducible with 13.0-RELEASE because it will not boot the computer with which I'm currently testing.

 

[Cath O'Deray]

Proposed fix: ⚙ D30880 fsck_ufs: fix background fsck in preen mode

Bug 256746 is closed, fixed. Commits:

1. <https://cgit.freebsd.org/src/commit/?id=0c5a59252c8e7b80b98521ebc23a415a05ff9594&h=main> (main)
2. <https://cgit.freebsd.org/src/commit/?id=fb2feceac34cc9c3fb47ba4a7b0ca31637f8fdf0&h=stable/13> (stable/13)

<https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=256746#c8>

… The next engineered release will be 13.1 which will contain this change.

---

If the file system has not been mounted or modified in between, then the second run should not mark it dirty. …

<https://lists.freebsd.org/archives/freebsd-current/att-0339/2021-07-16_00.53_typescript.txt>

1. marked clean
2. marked dirty

Postscript

Reproducible with a new disk:

 

[Cath O'Deray]

FreeBSD bug 259090 – UFS: bad file descriptor: soft update journaling can not be enabled on FreeBSD-provided disk images for 13.0-RELEASE and 13.0-STABLE – failed to write updated cg

• reproducible by the developer
• not reproducible by me with FreeBSD-12.3-PRERELEASE-amd64.vhd.xz on 2021-10-31

I don't recall testing types other than .vhd.

I assume that what bugs FreeBSD-13.0-RELEASE-amd64.vhd.xz also bugs FreeBSD-13.0-RELEASE-amd64.raw.xz and the two other types.

 

[Cath O'Deray]

FreeBSD bug 261944 – FFS/UFS: explain soft update journaling (SUJ) in documentation and in tunefs(8)

(Sincerely: I would have preferred this topic to be less noisy at its outset. A suitable explanation might have prevented the aggravation.)